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ABSTRACT 


This  thesis  attempts  to  document  the  events, 
environment,  decisions,  and  personnel  involved  in  the 
development,  implementation  and  life  cycle  management  of  a 
computer  software  application.  The  computer  application  is 
developed  using  a  prototyping  methodology  and  a  third 
generation  software  language  for  a  Department  of  the  Navy 
Headquarters  Command. 

The  data  are  presented  in  a  case  study  format  and  are 
analyzed  in  accordance  with  software  life  cycle  development 
principles  and  change  management  principles.  The  case 
methodology  was  considered  the  most  applicable  tool  to 
showcase  the  complexity  of  decisions  and  processes  of 
computer  systems  management.  The  case  studies  demonstrate 
the  importance  of  adhering  to  proven  software  development 
principles  throughout  £he  life  cycle  management  of  a 

t 

computer  application.  ( 


TABLE  OF  CONTENTS 


I.  INTRODUCTION  -  1 

A.  GENERAL  DESCRIPTION  -  1 

B.  METHODOLOGY  -  1 

C.  BACKGROUND -  2 

D.  RESEARCH  QUESTIONS  - 3 

E.  ORGANIZATION  OF  THESIS  -  4 

II.  CASE  METHODOLOGY -  5 

A.  INTRODUCTION  -  5 

B.  CASE  STUDY  FOR  RESEARCH  PURPOSES  -  5 

C.  ADVANTAGES  OF  CASE  STUDIES -  7 

D.  DISADVANTAGES  OF  CASE  STUDIES -  9 

E.  CASE  STUDIES  FOR  TEACHING  PURPOSES -  11 

F.  METHODOLOGY  OF  THESIS  CASE  STUDY -  13 

III.  CASE  STUDIES -  16 

A.  INTRODUCTION -  16 

B.  CASE  STUDY  ONE -  17 

C.  CASE  STUDY  TWO -  3  0 

D.  CASE  STUDY  THREE -  39 

E.  CASE  STUDY  FOUR -  44 

F.  CASE  STUDY  FIVE -  71 

G.  CASE  STUDY  SIX -  78 

IV.  ANALYSIS -  88 

A.  INTRODUCTION -  88 


v 


B.  CASE  STUDY  ONE  TEACHING  NOTE -  90 

C.  CASE  STUDY  TWO  TEACHING  NOTE -  102 

D.  CASE  STUDY  THREE  TEACHING  NOTE -  115 

E.  CASE  STUDY  FOUR  TEACHING  NOTE -  121 

F.  CASE  STUDY  FIVE  TEACHING  NOTE -  137 

G.  CASE  STUDY  SIX  TEACHING  NOTE -  142 

V.  CONCLUSIONS  AND  RECOMMENDATIONS  -  152 

A.  CONCLUSIONS -  152 

B.  LIMITATIONS  OF  THE  STUDY -  156 

C.  FUTURE  RESEARCH -  157 

D.  RECOMMENDATIONS -  158 

APPENDIX  A:  OA.S  INTERFACES -  160 

APPENDIX  B:  TIMELINES  AND  PERSONNEL  LISTS  -  164 

LIST  OF  REFERENCES -  17  2 

INITIAL  DISTRIBUTION  LIST  -  174 


vi 


I. 


INTRODUCTION 


A.  GENERAL  DESCRIPTION 

This  thesis  is  an  effort  to  document  the  events, 
environment  and  personnel  involved  in  the  development, 
implementation  and  life  cycle  management  of  a  computer 
software  application.  Also  documented  is  the  maturation 
process  of  the  organization  responsible  for  the  computer 
application.  The  data  are  presented  in  the  format  of  six 
case  studies  which  cover  a  period  of  two  years,  and  are 
analyzed  in  accordance  with  software  development  life  cycle 
management  principles  and  change  management  principles. 

B.  METHODOLOGY 

A  case  study  is  a  description  of  a  real  situation  that 
occurred  in  a  real  organization  [Ref.  l:p.  108],  Data 
pertaining  to  the  industry,  environment,  organization, 
product,  and  personnel  involved  in  the  situation  are 
presented.  The  focus  or  purpose  of  a  case  study  is  on  one 
or  several  key  issues,  decisions,  or  problems  requiring  a 
solution.  The  focus  of  this  case  study  is  on  decisions 
pertaining  to  development  of  computer  software  and  the 
consequences  of  these  decisions  on  the  software  and  the 
cognizant  organizations  over  a  period  of  time.  A  case  study 
is  an  effective  method  for  presenting  valuable  insight  into 
the  constant  technological  change  and  innovation 
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characteristics  of  the  computer  systems  management  field  and 
their  effects  on  management  and  organizational  change  [kef. 

2 : p.  370], 

The  data  within  a  case  study  are  presented  not  just  from 
one  person's  point  of  view,  but  rather  by  taking  into 
account  as  many  different  views  on  a  situation  as  possible. 
Data  are  presented  in  chronological  sequence  and  interwoven 
into  a  narrative  format.  The  narrative  format  facilitates 
the  search  for  facts,  questions,  and  probable  explanations 
for  the  situation  presente  by  the  case. 

The  data,  covering  two  years  of  the  life  cycle  of  the 
computer  application,  we:  voluminous.  Sources  utilized 
were  written  documentation,  interview  and  direct 
observation.  Presentation  of  the  data  in  a  chronological 
sequence  was  the  only  way  to  do  justice  to  the  rich 
description  of  all  the  factors  which  played  a  part  in  the 
decisions,  personnel  actions,  and  the  environment  of  the 
computer  application.  This  methodology  also  allows  for 
presentation  of  the  entire  range  of  details  and  processes 
surrounding  a  situation. 

C .  BACKGROUND 

The  computer  application  documented  is  the  Officer 
Assignment  Information  System  (OAIS) .  This  application  is 
used  by  Naval  Military  Personnel  Command  (NMPC)  for 
assignment  of  Naval  Officers.  The  purpose  of  OAIS  is  as  a 
tool  to  facilitate  and  improve  the  officer  assignment 
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process.  OAIS  is  a  menu-driven,  online,  real-time 
application  run  on  an  IBM  4381  mainframe  computer.  Each 
user  has  a  remote  display  terminal  and  keyboard  connected 
via  a  local  area  network  to  a  mainframe.  Personnel 
information,  activity  billets  and  automatic  orderwriting  is 
provided.  A  batch  mode  is  used  for  system  maintenance, 
updating  of  files  and  production  of  large  reports. 

Development  of  OAIS  took  place  in  the  early  1980's.  A 
prototyping  development  methodology  and  a  third  generation 
software  language  were  chosen  for  developing  OAIS.  At  this 
time,  prototyping  was  on  the  leading  edge  of  technology.  By 
using  prototyping,  NMPC  hoped  that  problems  concerning  cost 
overruns,  schedule  delays,  and  applications  not  meeting  user 
requirements,  problems  which  characterized  the  current  state 
of  the  software  development  industry,  would  be  avoided. 

D.  RESEARCH  QUESTIONS 

Two  items  are  of  particular  interest  in  this  thesis. 

The  first  question  addresses  what  could  have  been  done  to 
alleviate,  or  prevent,  problems  encountered  with  OAIS 
implementation  efforts.  The  second  question  addresses 
explanations  for  problems  encountered  in  OAIS  implementation 
efforts.  The  information  systems  department  at  NMPC  is 
currently  preparing  for  a  redesign  of  OAIS  into  a  database 
system.  The  command  is  interested  in  identification  of  any 
lessons  learned  from  prior  OAIS  implementations  and  any 
possible  problems  that  can  be  anticipated.  Of  particular 
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concern  for  NMPC  is  identification  of  any  long-term  effects 
resulting  from  implementation  of  the  prototype. 

E.  ORGANIZATION  OF  THESIS 

Following  this  introductory  chapter,  the  thesis  is 
organized  into  four  chapters  and  two  appendixes.  Chapter  II 
describes  the  case  methodology,  its  advantages  and  relevance 
as  both  a  research  and  teaching  strategy.  Chapter  III 
contains  the  six  case  studies  documenting  the  development, 
implementation  and  life  cycle  management  of  OAIS.  Chapter 
IV  is  an  analysis  of  each  case  study  within  the  case  series. 
The  analysis  is  focussed  on  software  development  life  cycle 
principles  and  management  of  change.  Chapter  V  contains 
responses,  conclusions,  and  recommendations  in  accordance 
with  the  stated  research  questions.  Appendix  A  contains  a 
description  of  OAIS  software  interfaces  with  other  computer 
applications.  Appendix  B  contains  timelines  and  lists  of 
personnel.  The  timelines  document  significant  events  during 
OAIS  development  and  implementation.  This  documentation  can 
be  of  assistance  to  both  case  study  students  and 
instructors,  enabling  them  to  follow  the  flow  of  events  and 
personnel  over  time. 
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IT.  CASE  .IKTHODOLOGY 

A.  INTRODUCTION 

This  chcipter  addresses  the  case  methodology.  The 
advantages  and  drawbacks  of  a  case  study  in  comparison  with 
other  research  methods  are  discussed.  The  use  and  benefits 
of  a  case  study  for  both  research  and  teaching  purposes  also 
are  explored. 

B.  CASE  STUDY  FOR  RESEARCH  PURPOSES 

A  definition  of  a  case  study  for  research  purposes  is  as 
follows : 

A  case  study  is  an  empirical  inquiry  that 

investigates  a  contemporary  phenomenon  within  its 
real  life  context;  when 

the  boundaries  between  phenomenon  and  context  are  not 
clearly  evident;  and 

multiple  sources  of  evidence  are  used.  [Ref.  3:p. 

23] 

In  this  definition,  case  study  research  stands  on  its 
own  as  a  research  strategy.  Prior  to  this  definition,  a 
common  misconception  held  by  those  uneducated  in  case 
methodology  was  that  research  strategies  were  of  a 
hierarchial  nature  [Ref.  3:p.  15].  Case  studies  were 
considered  as  being  at  the  bottom  part  of  the  hierarchy. 
Their  use  was  for  the  most  part  a  preliminary  to  other  types 
of  research.  Consequently,  case  study  usage  was  primarily 
limited  to  the  exploratory  stage  of  research.  Also  case 
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studies  were  viewed  as  consisting  of  only  one  small  part  of 
the  above  definition,  that  of  investigating  a  contemporary 
phenomenon  within  its  real  life  context.  This  is  evident 
when  case  studies  are  just  used  to  analyze  decisions, 
processes  or  events.  [Ref.  3:p.  23] 

Views  on  conducting  research  have  evolved  to  a  point 
that  each  different  type  of  research  strategy  is  viewed  as 
"a  different  way  of  collecting  and  analyzing  empirical 
evidence."  [Ref.  3:p.  15]  These  views  have  evolved  from 
the  narrow  niche  given  to  case  studies  and  the  wide, 
prescriptive  view  given  to  experiments.  Recognition  of  the 
best  type  of  research  strategy  is  now  based  on  subject 
matter  and  research  purposes.  Researchers  in  a 
"traditional"  sense,  where  emphasis  is  on  quantitative, 
controlled  events  and  results  that  are  generalizable  and 
replicable  have  recognized  the  benefits  derivable  from  case 
research.  Each  type  of  research  strategy  can  be  used  for 
each  of  the  three  different  purposes  of  research; 
exploratory,  descriptive  or  explanatory.  Which  strategy  is 
used  depends  on  the  following  three  conditions:  (1)  type  of 
research  question?  (2)  extent  of  control  over  behavioral 
events;  (3)  focus  on  contemporary  or  historical  events  [Ref. 
3 : p .  16]. 

The  five  recognized  research  strategies  within  the 
social  sciences  are  experiment,  survey,  archival  analysis, 
history  and  case  study.  Experiments,  history  and  case 
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studies  are  research  strategies  that  apply  to  a  "how"  or 
"why"  type  of  research  question.  Experiments  focus  on 
contemporary  phenomena,  but  require  control  over  behavioral 
events.  History  does  not  focus  on  contemporary  phenomena 
and  also  does  not  require  control  over  behavioral  events. 

As  previously  defined,  a  case  study  focuses  on  contemporary 
phenomena  in  which  there  is  no  control  over  behavioral 
events.  The  only  difference  between  history  and  case  study 
research  strategies,  besides  the  focus  of  the  research,  past 
versus  present,  is  that  case  study  researchers  have  an 
advantage  of  adding  direct  observation  and  interviews  to 
their  research  methodology.  [Ref.  3:p.  19] 

C.  ADVANTAGES  OF  CASE  STUDIES 

"As  a  research  endeavor,  the  case  study  contributes 
uniquely  to  our  knowledge  of  individual,  organizational, 
social  and  political  phenomena."  [Ref.  3:p.  14]  New 
situations,  interactions  and  problems  occur  every  day.  Case 
studies  provide  for  a  description  of  "holistic  and 
meaningful  characteristics  of  such  real  life  events  as 
individual  life  cycles,  organization  and  managerial 
processes,  neighborhood  change,  international  relations,  and 
maturation  of  industries."  [Ref.  3:p.  14] 

A  unique  strength  of  case  study  research  is  its  ability 
to  utilize  multiple  sources  of  evidence  in  presenting  data 
[Ref.  3:p.  20].  Such  evidence  includes  documents, 
artifacts,  interviews  and  observations.  This  characteristic 
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enables  presentation  of  data  from  all  points  of  view  and 
perception.  Rarely  does  one  view  of  a  situation  contain  all 
the  pertinent  facts  contributing  to  a  situation.  By  having 
access  to  multiple  sources  of  evidence,  the  full  story  or 
explanation  is  easier  to  piece  together.  Case  study 
research  allows  a  showcasing  of  cause  and  effect  factors  of 
a  situation  or  problem.  With  the  active  observation  of  a 
case  study  researcher,  many  details  are  provided  in  addition 
to  available  written  documentation.  This  facilitates  an 
ability  to  document  the  pc  ~ible  causes  and  effects  in  a 
relationship. 

Another  advantage  to  ^e  case  study  method  can  be  found 
in  the  use  of  qualitative  data.  Qualitative  data  is  in  the 
form  of  words,  not  the  numbers  traditionally  relied  on. 
Qualitative  data  does  have  some  advantages  over  quantitative 
data.  Qualitative  data  are  a  "source  of  well-grounded,  rich 
descriptions  and  explanations  of  processes  occurring  in 
local  contexts."  [Ref.  4:p.  15]  Words  gleamed  from 
interviews,  observations  and  documentation  can  indicate 
people's  attitudes,  internal  relations  among  personnel  and 
relative  power  and  influence  within  an  organization  [Ref. 
5:p.  49].  Words  possess  a  quality  of  "undeniability"  about 
them  [Ref.  4:p.  15].  "Words,  organized  into  incidents/ 
stories  provide  a  concrete,  vivid,  meaningful  flavor  that 
often  proves  far  more  convincing  to  a  reader .. .than  a  page 
of  numbers."  [Ref.  4:p.  15] 
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D.  DISADVANTAGES  OF  CASE  STUDIES 

A  major  difficulty  contributing  to  acceptance  of  the 
case  study  as  a  significant  research  strategy  is  that  the 
data  gathered  and  analyzed  are  qualitative  in  nature. 
"Numbers  don't  lie"  is  a  popular  cliche  in  support  of 
quantitative  data.  This  negative  viewpoint  is  based 
primarily  on  two  factors.  One  factor  is  that  words  can  have 
a  variety  of  meanings.  The  interpretation  given  to  them  by 
the  researcher  is  viewed  as  a  possibility  for  bias.  The 
numbers  faction  prefers  experiments  where  there  is  control 
over  events  and  the  results,  in  the  form  of  numbers,  are 
interpreted  the  same  by  all  analysts.  There  can  be  no  bias 
in  the  interpretation  of  numbers.  Secondly,  there  is  a 
preference  for  being  able  to  control  events  which  brings  up 
the  question  of  replicability.  Would  another  person  viewing 
the  qualitative  data  of  a  case  study  come  up  with  the  same 
conclusions?  Would  another  researcher  be  able  to  replicate 
the  entire  case  study  from  data  gathering  through  analysis? 
"Observations  tend  to  be  unique  and  non-replicable. "  [Ref. 
6:p.  2]  The  question  concerning  the  replicability  of  a  case 
study  adds  a  degree  of  uncertainty  to  the  research  process 
[Ref.  4 : p .  16]. 

Additional  uncertainty  also  comes  from  lack  of  detail  in 
the  documentation  that  case  study  researchers  provide  on 
their  methodology.  Some  past  case  study  results  have  been 
found  to  be  influenced/  biased  by  the  researcher.  A 
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contributing  factor  to  this  lack  of  documentation  is  the 
lack  of  accepted  and  standardized  methods  for  qualitative 
data  analysis,  and  a  lack  of  a  common  language.  [Ref.  4:p. 
16] 

There  are  several  other  drawbacks  to  the  case 
methodology.  The  preparation  of  case  studies  is  time- 
consuming  and  their  documentation  is  voluminous.  The  fact 
that  there  is  little  basis  for  scientific  generalization  is 
also  considered  a  major  stumbling  block  [Ref.  3:p.  20].  A 
typical  skeptic  of  case  study  research,  who  is  immersed  in 
the  quantitative  viewpoint,  looks  to  conclusions  of  the 
research  to  be  generalizable  to  other  situations.  This  is 
not  the  intent  of  case  study  conclusions.  "Case  study 
conclusions  are  generalizable  to  theoretical  propositions 
and  not  to  populations  or  universes."  [Ref.  3:p.  21]  They 
are  not  even  generalizable  to  other  organizations.  "In  this 
sense  a  case  study  does  not  represent  a  'sample'  and  the 
investigators'  goal  is  to  expand  and  generalize  theories 
(analytic  generalization)  and  not  to  enumerate  frequencies 
(statistical  generalization)."  [Ref.  3:p.  21] 

An  example  of  a  case  study  giving  emphasis  to  a 
theoretical  concept  is  as  follows:  the  Cuban  Missile 
Crisis.  This  exact  situation  will  never  happen  again,  but 
there  are  general  lessons  that  can  be  learned.  These 
lessons  include  "the  management  of  the  problem,  and  the  role 
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of  organizational  routine  in  shaping  events  and  decisions." 
[Ref.  7 : p .  295] 

The  case  study  as  a  research  strategy  has  been  used  in 
many  different  areas: 

policy,  political  science,  and  public  administration 
research; 

community  psychology  and  sociology; 
organizational  and  management  studies; 

city  and  regional  planning  research,  such  as  studies  of 
plans,  neighborhoods  or  public  agencies,....  [Ref. 

3 :p.  16]. 

The  use  of  case  study  research  has  also  proven  valuable 
to  the  information  systems  area.  "The  information  systems 
area  is  characterized  by  constant  technological  change  and 
innovation."  [Ref.  2:p.  370]  This  change  and  innovation 
has  an  impact  on  management  and.  organizational  issues  in  an 
information  systems  department.  Case  study  research  has 
been  able  to  provide  valuable  insights  into  these  issues 
[Ref.  2 : p .  370]. 

E.  CASE  STUDIES  FOR  TEACHING  PURPOSES 

According  to  Dorothy  Robyn,  "there  are  two  criteria 
potentially  present  in  any  learning  situation."  [Ref.  8:p. 
1]  These  two  criteria  are  the  content  or  specific  knowledge 
to  be  learned  and  the  learning  process.  The  learning 
process  concerns  itself  with  presenting  a  general  approach 
or  methodology  to  problem  solving  and  decision  making.  A 
student's  knowledge  and  ability  to  deal  with  the  reality  of 


life  outside  the  classroom  is  dependent  on  both  of  these 
criteria.  [Ref.  8:p.  1] 

Case  studies  basically  follow  the  principle  of  "learning 
by  doing."  Case  studies  present  real  life  with  all  of  its 
associated  complexity.  Experience  with  case  studies 
provides  students  with  exposure  to  a  wide  range  of  real  life 
situations  which  could  take  a  lifetime  to  experience 
personally.  This  experience  offers  a  basis  for  comparison 
should  the  student  run  into  the  same  situation  outside  the 
classroom  [Ref.  9:p.  56]. 

For  the  most  part,  a  classroom  setting  presents  facts 
and  situations  which  have  only  one  right  answer  [Ref.  8:p. 
2].  A  student  in  a  lecture/classroom  environment  is  a 
receiver  of  facts  [Ref.  9:p.  56].  Real  life  deals  with 
situations  in  which  not  all  the  relevant  facts  of  a  decision 
are  available  or  in  which  a  decision  is  not  straightforward 
in  that  there  is  no  right  solution.  "Case  studies  are 
valuable  lessons  in  teaching  students  the  habits  of 
diagnosing  problems,  analyzing  and  evaluating  alternatives 
and  formulating  workable  plans  of  action."  [Ref.  9:p.  56] 
Additionally,  students  must  learn  that  decisions  are  not 
just  made  from  an  analysis  of  the  facts.  "The  decision  is  a 
political  process ...  involving  power  and  influence."  [Ref. 

6:p.  2] 

Using  case  studies  in  learning  situations  provides  a 
student  with  an  opportunity  to  apply  theory  to  a  situation 
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within  the  safety  of  a  classroom  environment.  In  essence  a 
case  study  is  a  "simulated  experience."  [Ref.  l:p.  109]  An 
additional  benefit  is  an  ability  to  apply  known  theory  to 
contemporary  happenings  to  see  if  a  theory  holds  true.  If 
it  doesn't,  there  is  opportunity  to  search  for  reasons  for  a 
cause  and  effect.  Debates  between  students  over  a  cause, 
effect  and  solution  to  case  study  problems  provides  the 
benefits  of  requiring  them  to  question  their  assumptions  and 
to  defend  their  positions  on  issues.  Other  benefits  of  the 
use  of  a  case  study  in  a  classroom  include  teaching  students 
the  following  skills:  how  to  search  for  facts,  choose 
between  alternatives,  and  what  questions  it  is  essential  to 
ask.  [Ref.  8:p.  2] 

Retired  Navy  Admiral  Stansfield  Turner  believes  strongly 
in  utilization  of  case  studies  in  a  military  classroom.  He 
says,  "Many  of  the  education  programs,  are  simply  cramming 
officers'  heads  with  facts  rather  than  helping  them  to 
develop  the  skills  to  deal  with  difficult  problems  of 
leadership,  strategy  and  management."  [Ref.  10:p.  1] 

Admiral  Turner  feels  that  using  the  case  study  method  "will 
help  prepare  students  for  the  time  when  they  rise  to  the 
level  where  they  really  have  to  make  decisions  for  our 
country."  [Ref.  10 :p.  1] 

F.  METHODOLOGY  OF  THESIS  CASE  STUDY 

The  case  study  series  that  is  the  subject  of  this  thesis 
concerns  the  chronological  events  of  an  organization  during 


13 


a  period  of  two  years.  The  case  series  describes  the 

maturing  of  an  automated  data  processing  division  and  its 

interactions  with  other  departments  of  the  organization  in  a 

Department  of  the  Navy  Headquarters  Command.  An 

organizational  case  study  is  defined, 

. . .where  you  purposely  observe  the  entire  configuration  of 
individuals  and  groups  in  the  setting  of  an  organization, 
...and  you  observe  events  in  the  way  that  they  naturally 
unfold,  without  imposing  any  sort  of  experimental  controls 
or  treatments  whatsoever  on  what  it  is  you're  observing." 
[Ref.  6:p.  1] 

It  is  typical  of  organizational  case  studies  to  refer  to 
the  private  mental  state  of  individuals,  to  the  privately 
held  meanings  that  the  s  rrounding  organization  has  for 
them  and  to  features  of  tne  underlying  social  structure 
none  of  which  can  be  seen  directly.  [Ref.  6:p.  2] 

A  case  study  "treats  people  as  the  observable  agents  through 

which  the  unobservable  forces  of  the  organization  act." 

[Ref.  6 : p .  9] 

The  case  study  writer  was  a  member  of  the  automated  data 
processing  d  ivision  and  a  primary  participant  in  the  day-to- 
day  events  that  have  been  documented.  There  does  exist  the 
possibility  for  bias  in  the  writing  of  this  case  study,  but 
a  conscious  effort  was  made  to  avoid  any  potential  for  bias. 
For  example,  observation  consisted  of  memory  recall  by  the 
case  writer  and  verification  of  observations  by  several  of 
the  interviewees. 

The  setting  of  the  case  study  is  a  contemporary 
situation  in  that  computers  and  computer  systems  management 
is  a  relatively  new  field  within  the  past  two  decades.  Of 
particular  importance  in  this  case  study  is  the  use  of  a 
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prototyping  methodology  for  the  development  of  the  computer 
application  and  the  use  of  a  third  generation  software 
language.  The  evolution  of  a  computer  application  over  a 
two-year  time  period  and  the  maturing  of  the  organization 
responsible  for  its  development  in  terms  of  organizational 
structure,  policies  and  personnel  are  described.  Sources  of 
evidence  included  written  documentation,  interview  and 
direct  observation.  The  written  documentation  included  user 
and  system  documentation  on  the  application,  and  reports  on 
the  development  of  the  application  by  contractor  and  in- 
house  personnel.  Interviews  were  conducted  primarily  over 
the  phone  with  a  total  of  11  out  of  15  of  the  principal 
players  within  the  organization.  Personnel  interviewed 
covered  the  entire  hierarchy  of  management,  contractors, 
project  officer,  front  line  supervisors  and  worker 
personnel.  A  major  caveat  is  that  a  few  of  the  interviewees 
are  still  attached  to  the  organization.  Some  of  their  input 
may  have  been  tempered  by  still  being  involved  with  the 
computer  application.  The  data  presented  by  these 
interviewees  may  be  shaded  towards  protecting  the 
organization. 


III.  CASE  STUDIES 


A.  INTRODUCTION 

A  series  of  six  case  studies  is  presented  in  this 
chapter.  The  primary  theme  in  the  case  series  is  the 
development  and  life  cycle  management  of  the  Officer 
Assignment  Information  System  (OAIS) .  A  secondary  theme  is 
the  maturing  of  an  automated  data  processing  organization. 
Case  study  one  contains  the  background  events  of  OAIS 
development.  It  describes  the  implementation  of  the  OAIS 
prototype  and  covers  the  timeframe  of  November  1982  through 
October  1985.  Case  study  two  presents  the  events  preceding 
the  implementation  of  the  first  major  change  to  OAIS.  These 
changes  are  a  software  conversion  and  an  enhanced  order¬ 
writing  module.  The  time  period  covered  is  October  1985 
through  May  1986.  Case  study  three  concerns  the  failure  of 
the  new  version  of  OAIS.  Command,  user  and  project  officer 
reactions  to  the  failure  are  addressed.  Case  study  four 
presents  the  events  leading  up  to  a  second  try  at 
implementation  of  a  new  version  of  OAIS.  Also,  during  this 
time  period  of  May  1986  through  May  1987,  the  organization 
responsible  for  OAIS  development  is  transitioning  from  one 
with  an  emphasis  on  development  to  one  where  production 
issues  are  of  equal  importance.  Case  study  five  describes 
the  problems  with  the  second  implementation  of  the  new 


16 


version  of  OAIS.  Case  study  six  describes  the 
organization's  recovery  from  the  problems  generated  from  the 
OAIS  implementation  and  changes  made  to  deal  with  present 
and  future  computer  systems  management. 

Organization  charts,  where  applicable,  are  contained 
within  the  body  of  the  case  studies.  Appendix  A  contains  a 
description  of  OAIS  interfaces.  Appendix  B  contains 
timelines  and  lists  of  NMPC-47  personnel  for  case  studies 
two,  four  and  six.  These  timelines  document  important  OAIS 
and  NMPC-47  events  over  time.  This  documentation  can  be 
used  to  clarify  the  case  studies  and  be  used  in  conjunction 
with  the  teaching  notes  contained  in  Chapter  IV. 

B.  CASE  STUDY  ONE 
1 .  Background 

OAIS  (Officer  Assignment  Information  System)  is  the 
first  in  a  planned  series  of  four  applications  which  combine 
to  form  the  Naval  Military  Personnel  Distribution  System 
(NMPDS) .  NMPDS  was  designed  to  support  the  Distribution 
Division  (NMPC-4)  of  the  Naval  Military  Personnel  Command 
(NMPC) .  The  mission  of  NMPC-4  is  to  assign  officer  and 
enlisted  active  duty  personnel  in  accordance  with  the  needs 
of  both  the  Navy  and  the  individual's  career,  and  to  control 
the  manning  of  activities  as  specified  by  the  Chief  of  Naval 
Operations.  The  goal  of  the  NMPC-4  mission  is  to  "Put  the 
right  person  in  the  right  job  at  the  right  time." 
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2. 


Development  and  production  of  NMPDS  are  the 
responsibility  of  NMPC-47,  the  Distribution  Support 
Department.  As  of  October  1985,  NMPC-47  was  organized  as 
per  Figure  1.  The  Information  Systems  Development  branch, 
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Figure  l.  NMPC-47  Organization,  October  1985 
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N470 ,  was  responsible  for  all  development  and  production 
decisions  concerning  OAIS,  On-line  Distribution  Information 
System  (ODIS)  and  other  systems  which  fell  under  the 
umbrella  of  NMPDS.  The  data  administration  function, 
training  function,  Application  Programming  Shop  and 
Information  Center  made  up  the  rest  of  N470.  The 
Information  Systems  Support  branch,  N471,  included  Officer 
and  Enlisted  Error  Research  (help  desk) ,  Systems 
Administration  (network  hardware  and  software) ,  Scheduling, 
and  Configuration  Management.  The  Order  Support  branch, 
N472 ,  consisted  of  orderwriting  experts  and  order 
distribution.  Scheduling  was  responsible  for  running 
backups,  batch  updates,  and  daily,  weekly  and  monthly  OAIS 
reports.  These  reports  were  distributed  by  the  Order 
Support  branch,  N472,  to  assignment  and  placement  officers. 

3 .  Background  of  NMPDS 

NMPDS  was  designed  to  be  a  tool  to  help  optimize 
unit  manning,  minimize  personnel  turbulence,  minimize 
assignment  costs,  enhance  individual  career  development, 
improve  personalized  service  to  constituents,  and  maintain 
accurate  and  timely  personnel  and  distribution  information. 

Applicatic  ithin  NMPDS  were  planned  to  have  the 
following  characteristics : 
terminal  driven. 

interactive  data  entry  and  transaction  oriented, 
on-line  information  retrieval. 
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distributed  processing  oriented  to  functional  user. 

single  point  of  data  entry. 

standardized  processes. 

central  control  of  data,  resources  and 
telecommunications . 

modular  structure  for  expandability  and  flexibility. 

Two  major  guidelines,  top  management  commitment  and 
involving  the  user  in  all  phases  of  development  were  agreed 
upon  during  the  planning  stages  of  NMPDS  and  would  apply 
throughout  the  NMPDS  lifecycle. 

4 .  Officer  Assignment  nformation  System  (OATS) 

OAIS  automated  the  distribution  process  involved  in 
assignment  of  officers  tc  illets.  OAIS  was  designed  as  a 
tool  to  facilitate  and  improve  the  assignment  process  by 
providing  access  to  all  officer  distribution  files  through 
one  computer  application.  The  application  provides 
information  to  both  assignment  officers  (detailers)  and 
placement  officers. 

The  Officer  Assignment  Information  System  (OAIS)  is 
a  menu-driven,  on-line,  real-time  application  run  on  an  IBM 
4381  mainframe  computer.  Each  user  has  a  remote  display 
terminal  and  keyboard  connected  via  a  local  area  network  to 
a  mainframe.  By  accessing  either  the  Assignment  Officer 
Menu  or  Placement  Officer  Menu,  personnel  information, 
activity  billets  and  automatic  orderwriting  are  provided.  A 
report  menu  is  available  for  generation  of  specific  reports 
desired  by  users.  A  batch  mode  is  used  for  system 
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maintenance,  updating  of  files  and  production  of  large 
reports . 

The  manual  steps  involved  with  orderwriting  were 
automated  by  OAIS.  Before  OAIS,  orders  typically  took  four 
to  five  weeks  to  get  through  the  chop  chain  once  an  officer- 
assignment  match  was  made.  After  OAIS,  orders  could  be 
generated  and  sent  within  two  oo  three  days. 

Information  provided  by  OAIS  falls  into  three  main 
categories:  personnel,  activity  and  billet.  Personnel 

information  provided  by  OAIS  includes:  biographical, 
performance  evaluation,  duty  preferences,  and  career 
history.  Activity  information  provided  is  organization, 
administrative  and  mission  specific.  Billet  information 
includes:  billet  titles,  designators,  subspeciality  codes 

and  manning  requirements. 

The  network  operating  system  for  the  IBM  4381 
mainframe  is  IBM's  MVS  with  CICS  as  the  basic  communications 
software  in  the  multi-user  environment.  Communication 
between  terminals,  printers,  and  the  IBM  4381  mainframe  was 
conducted  through  the  use  of  a  bus  local  area  network.  The 
local  area  network  and  its  associated  bus  interface  units 
were  owned  by  NMPC-16.  Bus  interface  units  are  hardware  and 
contain  eight  available  ports  for  access  onto  the  network. 
Bus  interface  units  allowed  flexibility  in  location  and 
subsequent  moving  of  OAIS  terminals  within  an  office  space. 
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5 .  Users  of  PAIS 


An  assignment  officer  is  responsible  for  the 
personal  and  professional  interests  of  individual  officers 
and  assists  them  in  pursuing  their  career.  Placement 
officers  ensure  that  each  Naval  activity  is  optimally  manned 
with  the  best  qualified  officers.  The  job  of  being  an 
assignment  officer  or  placement  officer  included  a  lot  of 
stress.  There  were  pressures  from  senior  officers  to 
conserve  money  and  pressures  from  activities  to  get  the  best 
officers  for  their  command.  Assignment  officers  spent  most 
of  their  days  on  the  phone  talking  to  constituents  about 
upcoming  orders  or  counseling  on  career  moves.  A  typical 
assignment  or  placement  officer  was  a  Lieutenant  Commander 
or  Commander.  Often  times  they  came  from  leadership 
positions  of  executive  officer  equivalence.  They  were  used 
to  having  many  people  working  for  them.  As  an  assignment  or 
placement  officer  they  were  on  their  own  with  a  constantly 
ringing  phone  and  a  computer  application  called  OAIS. 

Quick  identification  of  personnel  and  billets  coming 
up  for  reassignment  are  available  with  OAIS.  The  major 
piece  of  information  that  drives  the  reassignment 
(availability)  process  is  the  Projected  Rotation  Date  (PRD) . 

Every  active  duty  officer  has  a  PRD  assigned  upon 
arrival  at  a  new  duty  station.  Depending  on  location  and 
type  of  job,  this  PRD  ranges  from  12  to  36  months.  The 
assignment  officer  will  begin  looking  for  billets  for 
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personnel  with  PRD's  six  to  nine  months  in  the  future.  The 
placement  officer  is  also  looking  at  filling  the  billets 
made  vacant  on  PRD's  and  advertises  billets  that  will  be 
coming  available.  Once  the  best  officer-billet  match  has 
been  determined  by  the  assignment  officer,  OAIS  facilitates 
the  officer-billet  match  approval  process  and  orderwriting 
process.  The  approval  process  consists  of  an  automated  chop 
chain  which  routes  the  proposed  officer-billet  natch  through 
the  appropriate  personnel.  The  automated  chop  chain 
facilitates  expediency  and  communication  between  the 
assignment  and  placement  officers.  The  orderwriting  process 
includes  decisions  on  training  (what,  where,  how  long)  and 
costing  of  orders.  The  information  necessary  for  this 
portion  of  the  process  was  automated,  replacing  paper  charts 
and  schedules. 

Improvements  were  made  bv  OAIS  in  three  categories: 
data  accuracy,  naval  resource  utilization  and  officer 
morale.  Improved  data  accuracy  resulted  from  automation  of 
previously  manually  maintained  distribution  information. 
Improved  naval  resource  utilization  resulted  from  having 
billet  assignments  made  from  a  larger  pool  of  candidates, 
decreased  incidence  of  inaccurate  reporting  instructions  on 
PCS  moves  and  misassignments .  improved  officer  morale 
resulted  primarily  from  a  reduction  in  the  amount  of  time 
required  for  the  assignment  process. 
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6 .  Software  Development 


OAIS  software  was  developed  using  a  prototype 
methodology  and  a  language  called  Application  Productivity 
Systems  (APS) COBOL.  APSCOBOL  was  developed  by  SAGE  Federal 
Systems.  It  is  a  third  generation  software  language 
designed  to  produce  COBOL  code  very  quickly.  Application 
generators  are  used  to  produce  source  code  from  high  level 
specifications,  reduce  programming  of  certain  system 
functions  and  enable  junior  programmers  to  produce 
sophisticated  code  with  little  training.  Additional 
benefits  of  APSCOBOL  were  its  advertised  transportability 
between  various  types  of  hardware  and  its  upwardly 
compatible  design.  Other  software  tools  used  during 
development  were  screen  painters  which  assisted  in 
configuration  of  data  entry  screens  and  report  generators 
which  facilitated  access  to  specific  data  from  files  for 
generating  reports. 

The  current  instructions  regarding  development  of 
information  systems  did  not  include  prototyping  as  a 
methodology.  Events  which  took  place  during  OAIS 
development  were  matched  as  closely  as  possible  with  the 
Life  Cycle  Management  Milestones  which  was  directed  under 
current  software  development  instructions. 

When  the  OAIS  project  was  first  established,  the 
hardware  on  which  the  application  operated  was  leased.  This 
decision  was  due  to  a  necessity  of  proving  the  quality  and 
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efficiency  of  OAIS  and  subsequently  NMPDS  before  additional 
resources  were  expended.  Also,  the  procurement  process  for 
the  hardware  was  not  completed  and  management  was  not  sure 
exactly  what  type  of  hardware  would  be  contained  in  the 
final  contract. 

The  benefit  of  an  upwardly  compatible  design  was 
that  in  subsequent  revisions  to  the  software  code,  only 
minor  changes  would  be  required  to  change  over  to  a  new 
version.  The  compatibility  feature  was  part  of  SAGE's 
design  architecture. 

The  initial  version  of  APSCOBOL  was  JK,  with  the 
next  version  called  one  point  seven  (1.7).  When  NMPC 
procured  APSCOBOL,  it  was  not  yet  available  commercially . 
NMPC  was  able  to  get  a  good  deal  on  the  price  and  be  on  the 
leading  edge  of  technology.  A  prototype  approach  was  used 
for  a  variety  of  reasons.  One  was  the  necessity  of 
automating  the  assignment  process  as  quickly  as  possible.  A 
study  group  had  been  studying  the  assignment  process  problem 
since  1978.  A  prototype  approach  also  would  assist  in 
determining  just  what  OAIS  was  to  do  by  giving  users  a 
concrete  example  to  illustrate  their  ideas  and  requirements 
on.  The  original  version  of  OAIS  was  just  automation  of  the 
manual  officer  assignment  process  for  the  Surface 
Distribution  Department. 
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7 .  Implementation  of  PAIS 


Development  and  implementation  of  OAIS  was  done  in  a 
modular  fashion.  In  November  1982,  the  Surface  detailers 
(NMPC-41)  were  used  to  test  and  modify  the  pilot  prototype. 
When  time  came  to  take  the  tested  and  approved  prototype  and 
complete  the  design  and  development  process,  the  Surface 
detailers  had  become  so  dependent  on  OAIS  that  the  decision 
was  made  by  NMPC-47  to  implement  the  prototype.  Over  the 
next  18  months  the  other  officer  oriented  departments  of  the 
Distribution  Division  were  brought  on-line.  See  Figure  2. 
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Figure  2.  NMPC-4  Organization 
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Implementation  of  OAIS  throughout  the  Distribution 
Division  was  done  in  a  modular  fashion  for  a  variety  of 
reasons.  Among  these  were  the  original  strategic  plan  of 
development  and  implementation  in  a  modular  fashion, 
problems  with  hardware  acquisition  and  the  need  for  minor 
modification  cf  OAIS  to  accommodate  each  different 
department.  A  prime  750  mainframe  computer,  which  is  non- 
IBM  compatible,  was  initially  leased  to  run  OAIS.  Next,  an 
IBM  4341  was  leased  until  inhouse  hardware  was  procured. 
During  this  period,  1982-1985,  the  scope  and  capabilities  of 
OAIS  could  not  be  expanded  to  satisfy  more  users. 

Assignment  and  placement  officers'  way  of  doing 
business  was  drastically  changed  by  OAIS.  Terminals 
replaced  paper  passed  from  desk  to  desk.  Secretarial  jobs 
changed  from  being  purely  clerical  to  a  required  interaction 
with  a  computer  and  computer-driven  reports  and  processes. 
Even  though  OAIS  was  available  on  every  desk,  many  personnel 
did  not  initially  use  the  computer  application.  Reasons  for 
non-use  by  the  assignment  and  placement  officers  ranged  from 
being  afraid  of  the  computer,  to  already  using  another 
personally-owned  computer  system,  to  being  stuck  in  the  old 
ways  of  having  their  secretaries  do  the  clerical  work  on  the 
computer  while  they  planned  in  a  manual  mode.  The  Medical 
Department,  within  NMPC-44,  was  one  of  the  divisions  using 
personally-owned  computers.  They  had  set  up  files  on  their 
constituents  using  a  database  system.  This  system  worked 
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fine  until  the  assignment  officers  transferred  and  took 
their  computers  with  them.  Mrs.  Clancey,  a  secretary  in 
NMPC-44,  refused  to  turn  on  the  computer.  She  continued  to 
use  her  manual  methods. 

In  the  Submarine  Department,  OAIS  was  utilized  far 
more  than  in  other  recently  implemented  departments.  This 
was  due  to  the  top  management  commitment  of  the  Submarine 
Department.  These  personnel  came  from  a  technical 
background  and  did  not  fear  the  computer  coming  into  their 
workplace.  Due  to  their  bosses'  support  of  OAIS,  all  the 
personnel  within  the  department  were  soon  proficient  on 
OAIS. 

Placement  officers  were  one  of  the  last  groups  of 
users  to  climb  onboard  the  OAIS  bandwagon.  Before  OAIS, 
placement  officers  maintained  their  personnel  lists  on  a 
manual  slate  with  a  strip  of  paper  for  each  officer  in  each 
billet  at  an  activity.  In  one  glance  they  could  determine  a 
status  of  their  billets  at  any  activity  With  OAIS  being 
constrained  by  the  number  of  lines  per  screen,  an  entire 
activity  could  not  fit  onto  one  screen.  In  the  eyes  of  a 
placement  officer,  this  was  a  major  drawback  to  the 
application.  Until  the  orderwriting  process  was  automated 
in  1985,  there  was  really  no  benefit  to  them  to  using  OAIS. 

8 .  User  Representatives 

Each  officer  distribution  department  was  represented 
by  a  user  representative,  selected  by  the  department  head. 
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This  user  representative  was  supposed  to  be  experienced  with 
OAIS  usage  and  functions.  The  responsibilities  of  user 
representatives  included  attendance  at  OAIS  user  meetings, 
reporting  back  to  their  department  issues  of  the  OAIS  user 
meetings,  and  bringing  problems  of  the  department  to  the 
meeting.  Also,  any  suggested  enhancements  to  OAIS  from 
individual  departments  were  to  be  routed  to  their  respective 
user  representative  for  review.  It  was  the  responsibility 
of  a  user  representative  to  pass  OAIS  information  around  the 
department,  so  that  each  individual  OAIS  user  was  not 
calling  the  help  desk. 

9 .  Training 

The  importance  of  training  was  discovered  in 
parallel  with  the  expansion  of  OAIS  users  to  the  Submarine 
and  Aviation  communities.  Training  had  not  been  a  problem 
with  the  Surface  Department  due  to  their  daily  involvemen'- 
with  development.  Their  sense  of  ownership  of  OAIS  promoted 
self-training.  CDR  Hazel  was  brought  on-board  in  July  1984 
to  be  the  Training  Officer  and  to  design  a  training  program 
and  OAIS  User  Manual.  CDR  Hazel  became  the  resident 
functional  expert  on  OAIS  and  on  the  specific  needs  of 
assignment  and  placement  officers.  The  Training  Development 
Project  was  established.  A  contract  was  arranged  with  Oak 
Ridge  Associated  Universities  in  Oak  Ridge,  Tennessee,  to 
develop  computer-aided  training.  This  training  would  serve 
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OAIS,  and  ODIS  users,  who  were  figured  to  number  in  the 
hundreds . 

10 .  Documentation 

Due  to  budget  constraints,  the  push  for  software 
development  and  implementation  of  the  prototype,  there  was  a 
significant  lack  of  operational  and  requirements 
documentation  on  OAIS.  Original  documentation  provided  by 
the  contractor  was  of  poor  quality.  There  were  no  detailed 
requirements  documents.  The  majority  of  the  documentation 
was  contained  within  the  comment  portion  of  the  code.  The 
first  user's  manual  was  published  in  January  1985.  Planning 
documents  included  functional  descriptions  for  OAIS  and 
NMPDS,  operational  requirements  for  OAIS,  system 
specifications  for  OAIS,  conceptual  design  for  OAIS,  program 
specifications  OAIS  and  data  base  specifications  for  NMPDS. 

C.  CASE  STUDY  TWO 
1 .  Background 

The  Officer  Assignment  Information  System  (OAIS) 
which  is  used  by  the  assignment  and  placement  officers  at 
Naval  Military  Personnel  Command  has  been  operational  for 
three  years.  The  organization  responsible  for  OAIS  is  on 
the  brink  of  many  changes:  personnel,  software  and  hard¬ 
ware.  The  personnel  responsible  for  planning  and  bringing 
the  OAIS  concept  to  reality  in  NMPC-47  and  at  the  contractor 
are  leaving.  A  new  project  officer  is  taking  over  at  a  time 
when  the  first  major  software  change  to  OAIS  is  in  progress. 
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The  first  of  four  IBM  mainframe  computers,  an  IBM  4381,  has 
been  delivered  after  an  exceedingly  long  procurement  period. 

2 .  New  PAIS  Project  Officer.  October  1985 

LT  Hopkins  arrived  at  NMPC  to  be  the  OAIS  Project 
Officer.  She  had  just  graduated  from  the  Naval  Postgraduate 
School  with  a  Master's  Degree  in  Computer  Systems 
Management.  She  relieved  CDR  Zeke  who  was  the  initial 
project  officer  for  the  OAIS  project.  CDR  Zeke  had  been 
responsible  for  the  growth  and  maturation  of  OAIS.  He  had 
seen  it  grow  from  a  fledgling  system  with  50  users  in  1982 
to  a  powerful  system  upon  which  NMPC  assignment  and 
placement  officers  were  now  heavily  dependent.  OAIS  users 
numbered  approximately  300. 

The  mindset  of  the  project  officers  when  LT  Hopkins 
arrived  concerning  the  contractor,  SAGE,  was,  "We  are  paying 
big  bucks  for  a  quality  product."  The  contractors  were 
taken  at  their  word  concerning  all  aspects  of  system 
development  and  production  and  they  had  been  proven  correct 
in  the  past. 

The  contracting  and  budget  portions  of  the  job  were 
a  particular  difficulty  for  LT  Hopkins.  The  primary 
contractor  for  OAIS  was  Oak  Ridge  National  Laboratory 
(ORNL) ,  a  division  of  the  Department  of  Energy.  The 
contract  with  ORNL  was  a  research  and  development  contract. 
There  was  not  much  substance  nor  specifically  spelled  out 
deliverables.  The  emphasis  was  on  the  research  and 
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development  of  the  prototyping  methodology.  SAGE  were  sub¬ 
contractors  of  ORNL.  In  order  to  get  contracting  changes 
through  to  ORNL,  approval  was  required  by  the  Total  Force 
Automated  Systems  Department  (NMPC-16) .  NMPC-16  was 
responsible  for  all  automated  data  processing  programs  and 
related  support.  Since  OAIS  was  now  three  years  old,  they 
viewed  contracting  charges  in  terms  of  maintenance  and  as 
they  conformed  with  the  Life  Cycle  Milestone  methodology. 

3 .  Personnel 

The  majority  of  0/TS  history  and  expertise  existed 
in  the  brains  of  CDR  Zeke  and  the  project  manager  at  SAGE. 
When  the  poor  quality  dor  mentation  was  delivered  by  SAGE, 
CDR  Zeke  said,  "Don't  worry  about  it,  we  know  what  we  are 
doing."  When  LT  Hopkins  relieved  CDR  Zeke,  the  project 
manager  at  SAGE  transferred  to  another  project.  The 
personnel  left  within  NMPC-47,  familiar  with  OAIS  history 
and  its  evolution  were  Mr.  Smith,  the  Technical  Director  and 
the  two  branch  heads,  CDR  Rice  and  CDR  Cinder.  CDR  Rice  and 
CDR  Cinder  had  been  on-board  less  than  a  year. 

Besides  CDR  Zeke,  the  other  major  player  in  the 
evolution  of  OAIS  was  CAPT  Dennis.  CAPT  Dennis  had  been  the 
NMPC-47  Department  Head  from  1983  to  August  1985.  CAPT 
Williams  had  just  recently  relieved  him. 

CDR  Hazel,  the  current  Training  Officer,  was  offered 
the  job  of  OAIS  Project  Officer  before  LT  Hopkins  reported 
aboard.  He  turned  it  down  as  it  was  described  as  a 
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caretaker  job  and  CDR  Hazel  always  enjoyed  a  challenge.  LT 
Hopkins  was  informed  of  CDR  Hazel's  expertise  by  CDR  Zeke 
and  he  recommended  that  she  utilize  CDR  Hazel's  knowledge. 

LT  Hopkins  kept  to  herself  and  did  not  try  and  make 
the  acquaintance  of  her  fellow  officers  within  the 
department. 

LT  Perkins  reported  on-board  in  December  1985.  She 
was  designated  as  the  replacement  for  CDR  Hazel,  who  was 
moving  up  to  be  the  Order  Support  branch  head.  CDR  Hazel 
left  LT  Perkins  alone  with  OAIS  for  two  weeks  while  on 
vacation.  With  his  assistance  on  orderwriting  procedures, 

LT  Perkins  became  a  functional  OAIS  expert  second  only  to 
CDR  Hazel.  CDR  Hazel  and  LT  Perkins  became  good  friends. 

CDR  Griffin  reported  on-board  in  April  1986.  He  had 
just  graduated  from  the  Naval  Postgraduate  School  and  was  to 
be  the  branch  head  of  Information  Systems  Support.  See 
Figure  3. 

4 .  NMPC-47  Organization 

CDR  Rice  and  CDR  Cinder  had  worked  out  an  informal 
matrix  management  plan  for  accomplishment  of  OAIS  taskings 
within  NMPC-47.  Programming  expertise  existed  and  was  being 
nurtured  in  the  Application  Programming  Shop  of  the 
Information  Systems  Development  branch.  The  original  plans 
for  OAIS  called  for  SAGE  to  create  the  first  version  of  OAIS 
and  for  the  Navy  to  take  over  maintenance  of  the  project 
afterwards.  Towards  this  end,  the  Application  Programming 
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NMPC  -  47 

May  1986 


Figure  3.  NMPC-47  Organization,  May  1986 


Shop  was  being  expanded  by  adding  experienced  Data 
Processing  Technicians  (DP's).  Expertise  on  the  external 
programs  with  which  OAIS  interfaced,  existed  in  the 
Information  Systems  Support  branch,  N471,  in  the  Officer 
Error  Research  section.  Officer  Error  Research  also  handled 
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users'  problems  concerning  AUTONOM  rejects  and  tracking  the 
status  of  officer  orders.  Hardware  and  systems  software 
expertise  was  also  contained  within  the  Information  Systems 
Support  branch,  in  the  Systems  Administration  section. 

When  LT  Hopkins  needed  assistance  or  technical 
advice,  she  went  to  the  experts  within  the  matrix.  Quite 
often,  personnel  in  the  Information  Systems  Support  branch 
were  tasked  by  LT  Hopkins  without  their  supervisors  being 
arfare  of  it.  LT  Hopkins  was  under  pressure  and  her  approach 
to  her  problems  was  blunt  and  aggressive.  She  would 
approach  enlisted  personnel  and  fellow  officers  with,  "I 
want  this  done  now." 

Personnel  in  the  Information  Systems  Support  branch, 
N47 1 ,  were  not  included  at  NMPDS  planning  meetings.  Though 
N471  personnel  kept  the  current  systems  going  from  day  to 
day,  any  problems  encountered  were  considered  status  quo. 
They  were  told  by  CDR  Cinder  that  OAIS  would  solve  all  of 
their  problems.  Focus  was  on  development  and  the  future. 
Towards  this  end,  CDR  Rice  and  CDR  Cinder  had  developed 
extensive  integration  plans.  Having  the  Order  Production 
Module  (OPM)  would  enable  the  combination  of  officer  and 
enlisted  order  generation.  They  envisioned  the  combination 
of  the  Officer  and  Enlisted  Error  Research  Sections. 

LT  Smith,  in  charge  of  the  error  research  divisions, 
felt  a  lack  of  connection  between  reality  and  the 
integration  plans.  She  convinced  CDR  Cinder  to  hold  off  on 
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the  integration  plans  for  the  error  research  division  due  to 
the  vast  differences  between  the  officer  and  enlisted 
programs  through  which  OAIS  and  EAIS  interfaced. 

LT  Smith  was  not  invited  to  attend  OAIS  User 
Representative  meetings  either.  Though  her  personnel  were 
tasked  by  LT  Hopkins  and  were  responsible  for  answering 
error  research  questions  and  investigating  AUTONOM  rejects, 
she  was  not  included.  However,  she  attended  as  many 
meetings  as  possible. 

5 .  Train j  no 

LT  Perkins  was  not  as  busy  as  she  was  used  to, 
having  just  come  from  an  officer-in-charge  billet.  A  new 
list  of  users  was  provided  by  Configuration  Management  on  a 
weekly  basis  to  LT  Perkins.  LT  Perkins  would  visit  the 
personnel  individually  and  offer  them  training.  Training 
consisted  of  hands-on  training  for  OAIS  and  ODIS.  In  some 
divisions,  the  OMS  user  representative  would  set  up 
training  for  their  new  personnel,  knowing  the  full  value  of 
training  by  LT  Perkins.  In  other  divisions  new  users 
decided  they  did  not  have  time  for  training  in  the  short 
turnover  period. 

LT  Perkins  felt  left  out  of  the  main  stream  of 
activities.  There  were  no  professional  nor  friendly 
overtures  from  personnel  within  the  OAIS  project  through 
which  she  would  naturally  have  interfaced. 
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6. 


When  LT  Hopkins  took  over,  plans  were  already 
underway  at  the  contractors  for  a  conversion  of  the  software 
version  of  OAIS.  The  first  version  of  APSCOBOL  was  JK  and 
it  was  developed  in  1981.  Since  that  time,  SAGE  had 
discovered  quite  a  few  problems  with  the  code  and  wanted  to 
enhance  their  product.  SAGE  announced  that  they  were 
discontinuing  support  for  the  JK  version. 

In  addition  to  the  software  conversion,  the 
orderwriting  portion  of  OAIS  was  redesigned.  The  current 
orderwriting  procedures  were  just  an  automated  version  of 
the  manual  method.  With  the  advent  of  automation  and  the 
input  of  several  serious  users,  shortcuts  and  enhancements 
were  needed  and  desired  to  the  orderwriting  process.  Also, 
it  was  planned  that  the  Order  Production  Module  would  take 
the  place  of  AUTONOM.  The  Order  Production  Module  would  be 
the  responsibility  of  NMPC-47,  in  addition  to  supporting  an 
increased  variety  of  order  formats  as  compared  to  AUTONOM 
capabilities.  Over  the  three  years  of  OAIS  production, 
reliance  on  AUTONOM  without  a  formal  level  of  service 
agreement  with  NMPC-16  had  been  a  cause  of  many  problems 
concerning  late  or  missing  updates  and  production  of  hard 
copy  orders. 

7 .  Navy  Programming  Responsibilities 

The  job  of  writing  the  new  orderwriting  procedures 
was  given  to  the  Application  Programming  Shop.  This  shop 
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consisted  mostly  of  programming  experienced.  Data  Processing 
Technicians  (DP) .  The  DP  in  charge  was  DPI  Brown.  DPI 
Brown  took  the  responsibility  for  rewriting  the  orderwriting 
procedures.  He  and  a  few  DP's  worked  relatively  on  their 
own  at  NMPC. 

The  contractors  were  responsible  for  conversion  of 
the  existing  OAIS  code,  both  batch  and  online,  and  the 
correction  of  several  trouble  reports.  The  grand  plan  was 
that  the  DP's  and  the  contractors  would  work  closely 
together,  so  that  the  DP's,  ^ould  become  more  familiar  with 
OAIS  programs  which  they  were  due  to  take  over  after  this 
conversion  effort.  Some  ^  DP's  and  systems  administration 
personnel  worked  with  the  contractors  at  their  site  in 
Rockville,  Maryland  and  assisted  with  the  conversion. 

There  was  little  coordination  between  DPI  Brown  and 
the  personnel  at  SAGE  prior  to  implementation.  Also,  a  late 
decision  was  made  concerning  the  OPM.  It  was  determined 
that  it  would  not  be  ready  in  time  for  a  May  implementation, 
so  the  new  version  of  OAIS  had  to  be  jury-rigged  to 
interface  with  AUTONOM.  Bits  and  pieces  of  the  new  software 
were  tested  separately,  but  there  was  not  a  complete  test  of 
the  OAIS  application  nor  a  systems  stress  test  to  check  the 
performance  of  the  hardware  with  the  new  version  of 
APSCOBOL. 

LT  Hopkins  asked  questions  about  testing  procedures, 
but  was  inexperienced  and  really  did  not  know  the  right 
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questions  to  ask.  Also,  at  this  time  there  was  no  separate 
test  vehicle  available  for  testing.  The  testing  that  was 
done  was  done  on  a  timesharing  basis,  with  batch  production 
jobs,  in  the  evening  hours. 

8 .  Preparation  for  Mav  1986  Implementation 

In  preparation  for  the  new  version  of  OAIS  set  to 
come  on-line  in  May  1986,  LT  PerKins  updated  the 
orderwriting  procedures  for  inclusion  in  the  OAIS  User 
Manual.  In  April,  CDR  Hazel  and  LT  Perkins  arranged 
training  sessions  with  the  OAIS  users  in  a  conference  room 
to  review  changes  to  OAIS  and  to  distribute  the  updated  OAIS 
User  Manual. 

On  the  first  day  of  production  for  the  new  version 
of  OAIS,  LT  Hopkins  waited  impatiently  in  her  office  to  hear 
how  OAIS  was  doing.  This  was  her  first  time  managing  a 
computer  software  project  as  well  as  being  her  first  major 
accomplishment  at  the  command. 

D.  CASE  STUDY  THREE 
1 •  Background 

A  new  version  of  OAIS  with  an  ungraded  version  of 
software  and  an  enhanced  orderwriting  module  was  implemented 
two  days  ago.  These  changes  were  the  first  major  changes 
made  to  OAIS.  A  combination  of  Data  Processing  Technicians 
and  contractor  personnel  worked  on  the  programming  portion 
of  development.  There  had  been  little  liaison  between  OAIS 
project  team  members  and  no  separate  test  vehicle  to  support 
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on-line  testing  of  OAIS  changes.  Up  until  this  point,  OAIS 
had  been  the  darling  of  Naval  Military  Personnel  Command 
both  for  the  enhancements  it  had  made  to  the  officer 
distribution  process  and  its  ability  to  provide  up-to-date 
information. 

2 .  Command  Decision 

CAPT  Williams,  NMPC-47  Department  Head,  slowly 
walked  back  from  conferring  with  his  boss,  Admiral  Duke. 
Admiral  Duke  was  the  head  of  the  Distribution  Division.  The 
hastily-called  meeting  concerned  the  poor  performance  of  the 
new  version  of  OAIS  that  had  just  been  implemented  two  days 
previously.  Admiral  Duke  had  received  numerous  complaints 
about  OAIS'  slow  response  time  and  downtime  (unavailability) 
from  the  department  heads  responsible  for  Surface,  Aviation 
and  Submarine  officer  distribution.  As  usual.  Admiral  Duke 
wanted  to  know  why.  He  did  not  understand  computer 
terminology  and  thus  it  was  even  harder  for  CAPT  Williams  to 
explain  the  complications.  All  the  Admiral  understood  was 
that  orders  were  not  being  processed  and  sent  out. 

Several  options  had  been  discussed  at  an  earlier 
meeting  with  NMPC-47  branch  heads.  One  option  was  to  keep 
OAIS  up  so  that  the  problems  and  causes  of  the  slow  response 
time  could  be  determined.  The  contractors  favored  this 
approach  since  the  majority  of  the  change  was  the  newly 
converted  software  code.  The  disadvantage  of  this  option 
would  be  a  continued  lack  of  orders  and  with  the  slow 
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response  time,  many  users  would  not  use  OAIS.  The  users 
wanted  the  old  version  of  OAIS  back  so  that  they  could  get 
orders  out.  By  going  back  to  the  old  version,  several 
enhancements  lobbied  for  by  the  users  and  an  enhanced 
orderwriting  module  would  be  lost.  These  users  were  still 
the  first  generation  of  users  and  remembered  life  without 
OAIS.  They  had  no  experience  with  making  the  best  even 
better.  NMPC-47  realized  that  going  back  to  the  old  version 
of  OAIS  would  mean  a  loss  of  credibility  with  users  and 
other  organizations  and  an  increase  in  resources  necessary 
to  solve  the  problem  off-line,  including  manpower,  dollars 
and  time.  Production  issues  involved  getting  OAIS  JK  back 
on-line,  running  all  the  updates  from  external  interfaces 
and  cancelling  the  updates  generated  by  the  new  version  of 
OAIS  to  external  interfaces.  The  users  would  lose  all  the 
work  that  they  had  been  able  to  get  done  on  OAIS  1.7  and  the 
time  needed  to  get  OAIS  JK  running  again  would  cause  OAIS  to 
be  unavailable  to  the  users. 

CAPT  Williams  told  YN3  Smith  to  contact  the  branch 
heads,  CDR  Rice  in  charge  of  N470,  Information  Systems 
Development  branch;  CDR  Griffin  in  charge  of  N471, 
Information  Systems  Support  branch;  CDR  Hazel  in  charge  of 
N472 ,  Order  Support  branch;  and  LT  Hopkins  who  was  the  OAIS 
Project  Officer.  All  players  had  met  on  numerous  occasions 
over  the  past  two  days  trying  to  determine  just  what  the 
cause  of  the  OAIS  problems  was.  Once  everyone  was  assembled 
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in  his  office,  CAPT  Williams  announced  his  course  of  action. 
"Take  OAIS  1.7  down  immediately  and  restore  OAIS  JK  (old 
version)  as  soon  as  possible.  At  yesterday’s  status  meeting 
I  was  told  it  would  take  14  hours  of  contractor  time  to 
restore  the  old  version.  I  want  an  estimate  of  when  the  old 
version  of  OAIS  will  be  available  for  detailer  use.  Jeff 
(CDR  Hazel) ,  I  want  your  staff  to  work  overtime  if  necessary 
to  get  any  priority  orders  out  manually.  That's  all." 

It  was  a  silent  group  that  walked  out  of  the  CAPT's 
office.  Very  rarely  had  they  seen  the  CAPT  this  angry.  CDR 
Rice  was  fuming.  OAIS  was  his  pet  project  and  had  been  the 
darling  of  NMPC  until  the  past  few  days.  LT  Hopkins,  a 
recent  graduate  of  the  Naval  Postgraduate  School ,  could  not 
believe  how  wrong  things  had  gone.  CDR  Hazel  thought  to 
himself,  I  tried  to  tell  them  it  wasn't  ready  and  shouldn't 
be  implemented.  Now  we'll  all  have  to  live  with  the 
consequences . 

3 .  Responses 

CDR  Griffin  was  the  most  recent  addition  to  NMPC-47, 
having  been  on-board  only  four  weeks.  CDR  Griffin  was  also 
a  recent  graduate  of  the  Naval  Postgraduate  School.  He  did 
not  want  to  have  to  tell  CAPT  Williams  that  it  would  take 
more  than  14  hours  of  downtime  to  restore  the  OAIS  JK 
version.  CDR  Griffin  thought  the  project  office  people 
always  conveniently  seemed  to  forget  the  production  portion 
of  the  business. 


42 


User  confidence  in  OAIS  was  shaken.  There  were  some 
dissatisfied  users  due  to  promises  of  enhancements  to  be 
contained  within  OAIS  1.7,  which  were  now  delayed  for  an 
indefinite  period  of  time. 

Tempers  were  high  and  finger-pointing  was  rife 
within  NMPC-47  and  SAGE.  DPI  Brown,  who  was  in  charge  of 
the  Navy's  portion  of  the  joint  effort  between  the 
contractor  and  the  Navy,  bore  the  brunt  of  the  blame.  The 
attitude  and  arrogance  on  the  part  of  the  DP's  was 
criticized. 

The  main  problem  identified  with  OAIS  1.7  was 
degraded  system  performance  due  to  the  enormous  demands  made 
on  the  system  from  the  converted  code.  This  slowed  response 
time  to  users  and  overtaxed  the  Central  Processing  Unit 
(CPU) .  When  CAPT  Williams  had  the  new  version  of  OAIS 
brought  down,  SAGE,  the  contractors,  were  all  for  keeping 
the  new  version  up  so  that  they  could  understand  and  work 
with  the  problem. 

LT  Hopkins  adopted  two  changes  to  her  management 
techniques  of  OAIS.  She  decided  to  modularize  OAIS  into 
smaller  portions  and  have  test  plans  drawn  up  for  each 
screen,  module,  program  and  interface  of  OAIS. 

4 .  Contract  Change 

About  this  time,  OP-01,  the  department  in  charge  of 
manning  plans  for  the  Navy,  slashed  the  DP  manning 
requirements  for  NMPC-47.  NMPC-47  knew  that  they  did  not 
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have  the  personnel  nor  the  expertise  to  maintain  OAIS.  This 
big  change  to  the  game  plan  required  internal  and  external 
changes . 

In  June  1986,  SAGE  was  approached  by  NMPC-47  top 
management  personnel,  CAPT  Williams  and  Mr  Smith,  concerning 
taking  over  the  maintenance  of  OAIS  in  addition  to  their 
current  responsibility  for  development.  This  change  in 
tasking  required  changes  to  the  contract. 

During  this  renegotiation,  SAGE  demanded  that  they 
be  given  full  control  over  JAIS  programming.  A  prime 
complaint  of  SAGE's  was  a  lack  of  control  for  the  full 
system  when  part  of  the  L  jgramming  was  being  done  by  Navy 
DP's.  SAGE  attributed  this  lack  of  control  to  being  a  major 
cause  of  the  recent  failure.  Having  complete  control  would 
enable  the  contractor  to  have  complete  confidence  in  and 
responsibility  for  the  results  when  it  came  time  for 
implementation  again. 

E.  CASE  STUDY  FOUR 
1 .  Background 

NMPC-47  had  just  put  the  old  version  of  OAIS  back 
into  production  after  two  days  of  user  complaints  concerning 
slow  response  time.  It  was  the  first  time  a  major  problem 
had  developed  with  OAIS.  LT  Hopkins  made  two  changes  to  her 
management  techniques.  She  wanted  OAIS  broken  into  modules 
and  test  plans  developed  for  each  screen,  menu  and  program. 
The  contractors  took  on  the  responsibility  for  both  OAIS 
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development  and  maintenance.  It  was  a  time  for  coming  up 
'ith  solutions  to  the  OAIS  problems  and  organizational 
change . 

2 .  Transition  of  N471  to  a  Full  Production  Division 

Throughout  the  fall  of  1986,  NMPC-47  experienced  the 
growing  pains  of  transition  from  a  development-oriented 
division  to  one  where  production  was  of  growing  importance. 
Up  to  and  including  the  present  time,  the  day-to-day  running 
of  the  department  was  driven  by  CDR  Rice's  priorities  and 
those  of  his  project  officers.  Even  though  OAIS  was  a 
production  application  with  all  intended  users  on-line,  OAIS 
was  handled  as  an  application  still  under  development. 

The  day-to-day  decisions  concerning  OAIS  production 
issues  were  handled  by  LT  Hopkins.  These  included 
production-oriented  decisions  such  as  scheduling  of  batch 
jobs,  updates,  downtime,  user  impact,  running  of  OAIS  user 
meetings,  production  of  OAIS  User  Bulletins  and 
responsibility  for  daily  messages  on  the  OAIS  sign-on 
screen. 

The  failure  of  OAIS  1.7  seemed  to  highlight  these 
growing  pains  and  brought  into  focus  such  issues  as  matrix 
management,  customer  support  and  training.  The  bottom  line 
was  that  users  had  become  highly  dependent  on  OAIS  for 
accomplishment  of  their  daily  work. 
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3 .  CDR  Griffin  Changes  to  N471 

CDR  Griffin  was  the  primary  force  behind  the 
transition  of  the  Information  Systems  Support  branch,  N471, 
into  the  branch  responsible  for  production  decisions.  In 
addition  to  the  issues  of  customer  support  and  training, 
systems  maintenance  and  production  scheduling  were  becoming 
more  and  more  important.  The  informal  matrix  management 
established  between  CDR  Rice  and  CDR  Griffin's  predecessor 
was  done  away  with.  Training  was  moved  from  N47  0  to  N471. 
See  Figure  4 . 

CDR  Griffin  changed  the  mission  of  the  error 
research  personnel  from  being  responsible  for  a  portion  of 
the  OAIS  user  interface  to  being  responsible  for  all 
customer  liaison  with  OAIS  users.  The  name  of  this  newly 
tasked  division  was  the  OAIS  Help  Desk.  LT  Perkins,  the 
current  Training  Officer,  was  identified  as  the  logical 
person  to  heal  up  the  OAIS  Help  Desk  because  of  her  current 
involvement  with  the  assignment  and  placement  officers  and 
her  functional  knowledge  of  OAIS. 

A  training  room  was  set  up  in  an  unused  conference 
room.  Approximately  eight  extra  terminals  were  set  up  for 
training  of  either  individuals  or  groups  of  users. 
Scheduling  of  the  conference  room  was  the  responsibility  of 
the  training  officer.  Training  evolutions  had  first 
priority  for  usage  of  the  room.  The  room  was  windowless 
with  no  air  circulation  or  ventilation. 
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Figure  4.  NMPC-47  Organization,  May  1987 


CDR  Griffin  developed  an  NMPDS  Crisis  Management 
Team.  This  team  was  composed  of  an  expert  from  each  area  of 
N471.  These  areas  included  Configuration  Management,  OAIS 
Help  Desk,  Systems  Administration  and  a  variety  of  other 
people  depending  on  the  problem.  This  group  was  headed  by 
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CDR  Griffin  and  manned  by  technical  personnel,  not  managers. 
Problems  were  explained,  solutions  discussed  and  a  decision 
to  remedy  the  situation  was  made  immediately.  See  Figure  4. 

4 .  Conflict  Between  N470  and  N471 

There  was  conflict  between  N470  and  N471  primarily 
due  to  allocation  of  resources  between  application  develop¬ 
ment  and  application  production.  Up  until  this  point  in 
time,  the  emphasis  in  NMPC-47  had  been  on  development 
issues.  OAIS  expertise  had  existed  only  in  N470,  the 
Information  Systems  Development  branch.  With  OAIS  usage 
growing  and  subsequently  dependence  on  the  application, 
other  considerations  were  necessary.  Maintenance  of  systems 
software  and  hardware  were  a  necessity.  Additionally, 
confusion  on  reporting  responsibilities  that  a  matrix 
management  system  wrought  on  functional  management  was 
exhibited. 

LT  Perkins  and  LT  Hopkins  were  constantly  at  logger- 
heads  over  responsibility  of  the  day-to-day  activities  of 
OAIS.  Both  CDR  Hazel  and  CDR  Griffin  agreed  with  LT  Perkins 
that  operational  control  of  OAIS  belonged  in  Information 
Systems  Support  branch,  N471,  vice  the  Information  Systems 
Development  branch,  N470. 

The  offices  of  LT  Hopkins  and  LT  Perkins  were 
separated  by  two  long  hallways.  LT  Perkins'  office  was 
located  next  to  the  OAIS  Help  Desk  and  Systems 
Administration  where  OAIS  operations  were  monitored.  When  a 
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glitch  developed  during  the  course  of  a  work  day  or  a  crisis 
was  identified,  LT  Perkins  had  to  consult  with  LT  Hopkins. 
This  wasted  valuable  time  concerning  both  a  fix  and 
notification  to  the  users  as  to  OAIS  status.  This  wasted 
time  during  a  crisis  added  to  the  adversity  between  LT 
Hopkins  and  LT  Perkins. 

Not  only  was  there  a  struggle  between  LT  Perkins  and 
LT  Hopkins,  but  there  was  one  between  the  branch  heads,  CDR 
Griffin  and  CDR  Rice.  There  was  disagreement  when  it  came 
to  allocation  of  resources,  both  personnel  and  money,  as 
well  as  the  priorities  of  systems  maintenance  and 
enhancement  versus  software  development.  Systems 
maintenance  was  continually  put  off  until  there  was  time  for 
it.  Time  seemed  to  be  found  on  Saturday  and  Sunday 
mornings . 

By  the  spring  of  1987,  full  control  of  day-to-day 
operations  of  OAIS  were  within  N471,  the  Information  Systems 
Support  branch.  The  upcoming  retirement  of  CDR  Rice 
hastened  the  process.  CDR  Rice's  replacement  was  LCDR  Wall. 
LCDR  Wall  was  more  receptive  to  new  ideas,  more  politically 
oriented,  as  well  as  being  junior  to  CDR  Griffin. 

LT  Perkins  took  over  full  responsibility  for 
production  decisions  and  scheduling  of  batch  jobs.  She  also 
took  over  responsibility  for  OAIS  User  Bulletin  publishing 
and  distribution. 
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5 .  OAIS  Help  Desk 


The  mission  of  the  OAIS  Help  Desk  was  to  improve  the 
current  level  of  user  assistance.  Instead  of  OAIS  users 
having  to  contact  various  representatives  within  NMPC-47  for 
assistance  with  different  problems,  the  OAIS  Help  Desk  would 
be  the  single  point  of  contact.  This  included  questions  on 
OAIS  usage,  orderwriting,  hardware  problems,  updates  of 
information  and  the  status  of  OAIS. 

Naturally  there  v  >re  growing  pains.  NMPC-47  workers 
had  to  learn  to  say,  "Have  you  contacted  the  Help  Desk?" 
instead  of  running  out  to  j.  ix  a  problem.  There  was  extreme 
difficulty  in  areas  wherr  ego  was  associated  with  power. 

One  of  these  areas  was  hardware  maintenance.  It  was  very 
hard  for  the  hardware  maintenance  personnel,  who  up  to  this 
time  had  been  worshipped  as  heros  due  to  their  knowledge  of 
computer  hardware,  to  become  part  of  a  total  customer 
service  concept.  Also  users  had  found  shortcuts  or  their 
favorite  helpers  and  constantly  called  them. 

The  enlisted  personnel  manning  the  help  desk  phones 
had  to  increase  their  knowledge  of  OAIS  as  well  as  learn 
patience  for  frustrated  users.  When  OAIS  did  not  work 
correctly,  was  down  or  contained  bad  information,  the  people 
that  bore  the  brunt  of  user  frustration  were  the  OAIS  Help 
Desk  personnel  and  LT  Perkins.  If  an  officer  was  not 
satisfied  with  the  answers  provided  by  the  OAIS  Help  Desk, 
they  would  call  CDR  Griffin,  CDR  Rice  or  even  CAPT  Williams. 
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Users  had  to  learn  that  the  OAIS  Help  Desk  would  get  the  job 
done. 

The  phone  calls  to  LT  Hopkins  concerning  OAIS  Help 
Desk  issues  were  of  particular  note.  LT  Hopkins  would 
usually  proceed  to  investigate  the  problem  on  her  own 
without  informing  LT  Perkins  until  later. 

LT  Perkins  spent  a  lot  of  her  time  educating  users 
with  reminders  of,  "Next  time  please  call  the  Help  Desk"  and 
building  customer  trust  in  herself  and  her  personnel's 
performance . 

6 .  OAIS  Help  Desk  Phone  Loo 

A  phone  log  procedure  was  implemented  in  order  to  be 
able  to  track  incoming  requests  and  to  conduct  a  follow-up 
when  users  called  again.  Several  cases  of  help  requests  not 
being  fulfilled,  with  users  complaining  to  CDR  Griffin, 
fueled  this  change. 

User  name,  time,  date  of  call  and  complaint  were 
logged.  Calls  pertaining  to  hardware  problems  or  User  Id's 
needing  reset  were  given  a  control  number  and  sent  to  the 
appropriate  section  of  N471,  the  Information  Systems  Support 
branch  for  correction.  This  process  established  an  auditing 
activity  of  the  log  book  by  LT  Perkins  from  which  she  could 
detect  the  flavor  of  calls  and  identify  any  particular 
trends  or  problems  pertaining  to  training. 
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7 .  Growth  of  User  Base 


As  each  day  went  by,  the  number  of  users  on  OAIS  and 
ODIS  continued  to  rise  steadily.  Requests  were  received 
from  outside  of  NMPC  for  access  to  the  application.  A  major 
policy  decision  was  made  that  NMPDS  information  was  just  for 
Distribution  Department  purposes.  Problems  were  encountered 
as  the  number  of  users  increased. 

8 .  Port  Pirates 

There  were  more  terminals  than  there  were  ports  on 
the  bus  interface  units  of  the  local  area  network.  Primary 
users  of  NMPDS  were  designated  as  NMPC-4  and  NMPC-2 
personnel.  Other  users  were  secondary.  Primary  users  were 
assigned  by  division,  a  range  of  port  numbers  (one  for  every 
user)  which  were  theirs  to  use.  Specific  port  assignment 
was  left  up  to  a  division.  Secondary  users  were  assigned  a 
few  port  numbers.  The  policy  for  secondary  users  was  use 
OAIS  and  then  sign  off  the  port  so  that  other  personnel 
could  have  access.  If  more  personnel  than  there  were  ports 
available  wanted  to  get  on  OAIS,  they  had  to  port  pirate. 

Port  pirating  involves  trying  various  port  numbers 
to  see  if  they  were  vacant  to  get  on  OAIS.  If  a  primary 
user's  port  was  pirated  he  would  call  the  help  desk  for 
resolution.  The  port  pirate  was  bumped  off  the  pirated  port 
and  the  primary  user  was  able  to  sign  on.  Particularly  on  a 
Monday  morning,  a  large  amount  of  the  calls  to  the  help  desk 
were  those  complaining  of  port  pirates. 
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9 .  PAIS  Dependence 


A  crisis  seemed  to  develop  quickly  whenever  a 
problem  with  OAIS  occurred,  whether  it  be  a  bad  back-up  tape 
from  the  Officer  Master  File  (OMF)  or  a  hardware  failure. 
This  crisis  environment  was  due  to  the  heavy  dependence  of 
assignment  and  placement  officers  on  OAIS.  Also,  senior 
personnel  within  NMPC  had  come  to  rely  on  OAIS  to  supply 
them  with  information  on  personnel,  tracking  of  orders  and 
for  answering  questions  from  Admirals  and  the  Fleet.  Due  to 
this  dependence  on  OAIS,  CDR  Griffin  required  LT  Perkins  or 
one  of  her  personnel  to  personally  deliver  an  OAIS  User 
Bulletin  or  message  concerning  OAIS  downtime  to  NMPC-47's 
Captain  and  the  Admiral  (NMPC-4) . 

10.  Experienced  Users 

The  users  were  becoming  comfortable  with  computer 
usage  and  OAIS.  With  this  comfortableness  the  users  started 
coming  up  with  better  ways  of  doing  things  and  ideas  on 
automating  other  parts  of  their  workload.  Their  ideas  were 
turned  into  LT  Hopkins  in  the  form  of  a  Software  Change 
Proposal  (SCP) .  LT  Hopkins'  response  was  that  NMPC-47  would 
consider  the  changes  after  the  new  version  of  OAIS  came  up. 

It  was  during  this  timeframe  that  shortcuts  to 
circumvent  the  chop  chain  and  unprotected  data  fields  within 
OAIS  were  discovered  by  the  OAIS  hackers  (expert  users) . 

When  these  were  discovered  by  NMPC-47,  fixes  were  quickly 
implemented.  One  of  the  hacker  changes  included  using  one 
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of  the  orderwriting  screens  for  sending  messages  to  other 
personnel  in  the  chop  chain.  This  discovery  prompted  an 
addition  of  a  message  screen  for  such  a  purpose  in  the  new 
orderwriting  menu  to  be  implemented  with  the  1.7  conversion 

The  Aviation  Department  was  using  a  screen  designed 
for  the  Submarine  Department.  The  screen  was  designed  to 
keep  track  of  hulls  and  Unit  Identification  Codes  (UIC) 
assignments  for  new  submarines,  but  the  Aviators  were  using 
it  for  their  in-house  telephone  directory. 

Other  abuses  of  OAIS  included  personal  utilization 
of  information  covered  by  the  Privacy  Act.  Such  abuses 
included  checking  out  a  medical  doctor  or  lawyer's  history 
and  fitness  reports  prior  to  using  their  services. 

Screen  by  screen  access  was  monitored  by 
Configuration  Management.  Decisions  concerning  access  or 
denial  of  access  came  through  the  chain  of  command  of  a  new 
user,  to  their  user  representative  and  lastly  to  LT  Perkins 
for  final  approval.  One  security  precaution  had  been 
specifying  the  rank  level  for  fitness  report  review.  For 
example,  an  Ensign  was  typically  granted  access  to  only 
Ensign  or  Lieutenant  Junior  Grade  fitness  reports  unless 
their  job  required  other  access. 

11 .  OAIS  user  meetings 

OAIS  user  meetings  were  held  on  an  as-needed  basis. 
They  were  called  for  and  run  by  LT  Hopkins.  User 
representatives  from  each  division  attended  on  a  sporadic 


basis.  The  focus  of  each  meeting  was  usually  development- 
oriented.  Users  continuously  turned  in  additional 
requirements  and  enhancements  for  OAIS  to  LT  Hopkins.  All 
change  requests  were  put  on  hold  until  OAIS  1.7  was 
implemented.  LT  Perkins  attended  these  meetings,  but  rarely 
had  anything  to  discuss  save  trouble  reports  called  in  to 
the  OAIS  Help  Desk. 

12 .  OAIS  User  Bulletins 

Information  concerning  OAIS  was  also  promulgated  by 
use  of  OAIS  User  Bulletins:  These  OAIS  User  Bulletins  were 

sent  to  every  OAIS  user  on  an  as-needed  basis.  Green  paper 
was  used  so  that  they  wo'  i  be  easily  distinguishable  in  a 
basket  full  of  papers.  Information  such  as  scheduled 
downtime  on  a  weekend  or  a  trend  of  problems  noticed  by  the 
help  desk  were  contained  on  a  User  Bulletin. 

13 .  Training 

LT  Perkins  was  still  the  Tr..  ling  Officer.  Training 
continued  as  before.  Some  departing  OAIS  users  scheduled 
training  for  their  reliefs  as  they  new  the  full  value  of 
training  by  LT  Perkins.  In  other  divisions  new  personnel 
decided  they  did  not  have  time  for  training  in  the  short 
turnover  period.  New  users  got  some  on-the-job  training 
from  their  predecessor  and  any  problems  they  encountered 
they  called  the  OAIS  Help  Desk. 

These  calls  required  OAIS  Help  Desk  personnel  to 
become  quite  familiar  with  all  aspects  of  OAIS  and  brought  a 
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slight  change  in  their  mission.  Instead  of  just  correcting 
errors  in  the  final  product,  orders,  or  notifying  the 
correct  department  for  a  hardware  problem,  OAIS  Help  Desk 
personnel  learned  to  operate  screens  and  understand  the 
various  portions  of  the  officer  assignment  process.  The 
acquisition  of  the  whole  picture  at  the  help  desk  increased 
the  number  of  "experts"  on  OAIS,  who  could  be  turned  to  in 
times  of  crisis. 

14 .  Morale  of  N47's  Data  Processing  Technicians 

Morale  of  NMPC-47  DP's  was  a  constant  concern.  Many 
of  the  positions  were  filled  by  first  class  or  personnel  on 
their  first  tour  with  the  Navy.  First  class  tours  were  six 
years.  Unless  they  were  able  to  get  into  the  elite  groups 
of  the  Information  Center  or  Systems  Administration,  many 
got  out.  Personnel  new  to  NMPC-47  were  started  out  either 
at  a  help  desk  or  in  Scheduling.  The  Data  Processing 
Technicians  viewed  the  help  desk  job  as  that  of  secretary, 
which  in  their  minds  was  a  far  cry  from  being  a  computer 
programmer.  After  some  time  they  could  be  moved  to  other 
parts  of  the  branch,  in  which  their  training  would  be  of 
use,  but  there  was  no  designated  path  of  career  progression. 
Changes  in  job  description  and  division  were  determined  by 
performance  and  vacancies.  The  expert  status  conveyed  upon 
the  members  of  the  OAIS  Help  Desk  significantly  increased 
their  morale. 
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The  majority  of  DP's  want  to  program.  There  was 
little  programming  to  be  done  due  to  the  integration  and 
sharing  of  resources  called  for  in  the  NMPDS  plan.  It  was 
an  accountability  matter  for  the  contractors  that  if  they 
are  held  responsible  for  the  program,  they  did  not  want, 
anyone  else  to  be  allowed  to  make  changes  to  it.  The  DP's 
responded  to  added  pressures  and  high  cost  of  living,  which 
is  synonymous  with  working  in  Washington  D.C.  at  a 
headquarters  command,  by  getting  out  of  the  service.  Many 
were  able  to  find  lucrative  jobs  with  computer  companies  and 
make  more  money. 

15 .  System  Administration  Improvements 

A  test  environment  for  OAIS,  called  TOAIS,  was 
developed  oy  the  Systems  Administration  division.  With  CDR 
Griffin  giving  Systems  Administration  the  emphasis  it 
needed,  future  plans  for  hardware  and  software  were 
expanded. 

a.  Security 

A  major  issue  in  October  1986  was  the 
introduction  of  a  security  system  for  signing  into  NMPDS. 
This  security  system  would  increase  overall  security  and 
data  integrity.  The  current  procedures  required  specific 
signon  procedures  for  each  of  the  applications  under  NMPDS. 
The  goal  was  a  standard  sign-on  procedure.  The  first  _ep 
was  incorporation  of  an  overall  shell  security  system, 
called  RACF,  which  when  successfully  accessed  would  allow 
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access  to  the  other  applications  within  NMPDS  with  their 
individual  passwords.  With  RACF  in  place,  users  were 
required  to  remember  their  RACF  password  and  their  password 
for  each  application. 

When  RACF  was  implemented  it  was  discovered  that 
many  users  did  not  have  their  own  User  Id's,  but  used  those 
of  other  personnel.  This  was  c  security  violation.  Each 
user  is  given  capabilities  and  access  to  certain  screens 
within  OAIS  based  upon  the  job  they  are  to  fill  in  the 
assignment  process.  It  was  also  discovered  at  this  time 
that  some  assignment  and  placement  officers  had  given  their 
User  Id's  to  their  secretaries  to  do  their  work.  In  essence 
this  was  also  a  security  violation  as  well  as  an  avoidance 
of  using  OAIS. 

It  took  a  lot  of  work  to  get  the  RACF  system 
working  properly.  Users  had  to  acquire  User  Id's  and  they 
frequently  forgot  their  password  and  had  to  call  the  help 
desk  to  have  it  reset.  The  help  desk  personnel  had  to 
ensure  that  the  person  who  was  calling  for  a  User  Id  reset 
was  actually  the  user. 

b.  NMPDS  Dial-Up  Capability 

Users  had  become  more  and  more  dependent  on  OAIS 
and  ODIS.  To  facilitate  detailer  trips  to  the  field,  a 
dial-up  capability  for  OAIS  and  ODIS  was  implemented. 

Through  the  establishment  of  an  800  number,  procurement  of 
lap-top  microcomputers  and  modems  with  secure  calculator 
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generated  passwords,  detailers  were  able  to  access  OAIS  and 
ODIS  from  the  field.  This  greatly  decreased  their  manual 
paperwork,  impressed  constituents  in  the  field  and  increased 
constituent  confidence  in  the  detailing  system. 

If  a  detailer  trip  was  going  to  the  west  coast, 
special  arrangements  were  made  through  the  help  desk  to  have 
OAIS  stay  operational  longer  than  the  usual  downtime  of 
1800.  This  delayed  backups  '.id  batch  jobs  in  the  evening, 
put  if  planned  far  enough  in  advance,  could  be  handled 
without  difficulty  or  delay  in  workload. 

16 .  Software  Maintenance  for  OAIS 

Maintenance  to  the  older  version  of  OAIS  was  being 
done  by  the  DP's  in  the  Application  Programming  Shop  within 
N470 ,  the  Information  Systems  Development  branch,  on  an  as- 
available  basis.  This  maintenance  tasking  was  to  be  just 
until  OAIS  1.7  came  up.  The  contractors  did  not  have  enough 
personnel  to  handle  development  and  maintenance  due  to  the 
recent  contract  change. 

Most  of  the  changes  were  maintenance-oriented,  with 
only  a  few  high  priority  development  changes.  The  change 
process  involved  changes  to  the  program  but  no  changes  to 
documentation.  The  development-oriented  changes  included 
giving  OAIS  the  ability  to  handle  the  processing  of  Release 
from  Active  Duty  (RAD)  orders,  Resignation  orders  and 
Retirement  orders.  The  change  for  RAD  and  Resignation 
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orders  occurred  in  December  1986  and  the  change  for 
Retirement  Orders  occurred  in  March  1987. 

These  changes  increased  OAIS's  usage.  Previous  to 
this,  Resignation  and  Retirement  (RAD)  orders  had  to  be 
./ritten  manually.  The  manual  process  took  far  too  long  and 
chops  on  the  orders  were  needed  from  a  variety  of  personnel 
serving  in  several  different  divisions.  Personnel  in  CDR 
Hazel's  division  had  to  type  these  manual  orders.  CDR  Hazel 
was  always  looking  for  ways  to  improve  OAIS  and  reduce 
manual  work.  He  worked  closely  with  the  N470  programmers  to 
have  OAIS  changed  to  accommodate  these  two  order  formats. 

With  a  few  small  exceptions,  all  types  of  orders 
could  now  be  written  on  OAIS.  Due  to  the  changes  made  by 
CDR  Hazel,  the  orders  which  still  had  to  be  typed  manually, 
due  to  OAIS's  inability  to  handle  them,  were  down  to 
approximately  five  a  day.  This  is  a  significant  amount  when 
approximately  30,000  sets  of  orders  (basic  orders  and 
modifications)  were  sent  out  annually.  NMPC-2,  who  is 
responsible  for  RAD,  Resignation  and  Retirement  orders,  was 
now  a  full-fledged  user  of  OAIS. 

17 .  ODIS  Improvements 

During  this  time,  rapid  advances  and  changes  were 
being  implemented  in  ODIS.  These  changes  made  the  life  of 
assignment  and  placement  officers  easier.  The  ability  to 
get  Officer  Data  Cards  (ODC)  by  social  security  number  from 
ODIS  was  implemented  in  December  1986.  Officer  Data  Cards 


60 


carry  a  condensed  version  of  an  officer's  personnel  history 
on  a  single  sheet  of  paper.  These  ODC's  were  handy  for 
quick  reference  and  detailing  trips.  ODIS  was  able  to 
provide  a  one  to  two  day  turnaround  as  opposed  to  requesting 
the  service  from  NMPC-16  and  waiting  a  week  to  ten  days. 

ODIS  training  and  abilities  were  advertised  heavily 
during  this  time.  Many  of  the  reports  and  information 
changes  that  assignment  and  placement  officers  desired  and 
had  submitted  in  the  form  of  Software  Change  Proposals 
(which  were  on  hold  until  implementation  of  the  new  version) 
were  available  through  the  iatabase  of  ODIS.  ODIS  was  not 
quite  as  "user  friendly"  as  OAIS.  Commands  were  in  an 
English-like  language  and  knowledge  of  some  boolean  algebra 
was  required  to  operate  the  database.  The  Information 
Center  was  available  for  assisting  users  with  ODIS. 

Additionally,  through  ODIS,  an  electronic  mail 
system  was  available  to  all  users.  The  electronic  mail 
system  required  a  separate  password,  as  did  ODIS  usage. 
Electronic  mail  was  utilized  on  a  s  oradic  basis  throughout 
NMPC-4  with  s  ;me  departments  taking  i.ull  advantage  of  the 
system  and  others  ignoring  it. 

18 .  Contractor  Project  Management 

Throughout  July  and  August  of  1986,  the  contractors 
tore  OAIS  apart,  broke  it  down  into  workable  size  modules  as 
per  LT  Hopkins'  direction  and  identified  areas  requiring 
work.  LT  Hopkins  allowed  the  contractor  to  start  from 
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scratch  in  fixing  bugs  and  programming/redesigning  Navy 
code . 

In  September,  the  contractors  requested  an  OAIS 
functional  expert  from  the  Navy  to  assist  on  a  daily  basis, 
to  make  decisions  and  guide  fixes  on  the  reprogrammed 
version  of  OAIS.  LT  Hopkins  knew  she  did  not  have  the 
expertise  to  assist  the  contractors,  but  at  the  same  time 
she  felt  the  need  to  be  continually  looking  over  their 
shoulders . 

CDR  Griffin  wanted  CDR  Hazel  to  be  this  functional 
expert.  CDR  Griffin  was  determined  to  have  OAIS  1.7  work 
the  next  time  it  came  up,  as  his  division  bore  the  brunt  of 
user  dissatisfaction. 

CDR  Hazel  wanted  to  be  the  functional  expert 
assisting  the  contractors.  He  had  also  borne  some  abuse 
from  the  assignment  and  placement  officers  for  the  failure 
of  OAIS  in  May  1986,  being  the  closest  to  them  due  to  his 
previous  job  as  Training  Officer.  CDR  Hazel  felt  like  one 
of  the  plank  owners  of  OAIS.  He  felt  he  owed  it  to  himself, 
the  department  and  the  users  to  make  it  work.  CDR  Hazel 
felt  he  finally  had  someone  on  his  side  in  the  form  of  CDR 
Griffin.  Both  knew  user  issues  came  first  and  worked 
towards  this  end. 

CDR  Griffin  had  to  take  the  decision  concerning 
designation  of  the  functional  expert  to  CAPT  Williams  as  CDR 
Rice  did  not  want  CDR  Hazel  involved.  CDR  Rice  and  his 
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project  officers  were  responsible  for  liaison  with  the 
contractor  and  wanted  to  keep  it  that  way.  LT  Hopkins  did 
not  have  any  objections  to  CDR  Hazel's  involvement,  she 
wanted  to  get  back  out  there  with  a  quality  product. 

CDR  Hazel  was  designated  as  the  functional  expert  to 
assist  SAGE.  He  spent  every  day  of  September  and  October 
with  the  contractors.  He  assisted  in  the  identification  of 
bugs,  instructed  on  fixes  and  made  decisions  on  functional 
issues.  He  was  also  able  to  correct  minor  things  which, 
though  of  a  low-level  priority,  still  bothered  him.  These 
included  standardizing  messages  and  making  error  messages 
understandable  to  the  users  instead  of  being  in  programmer 
code.  CDR  Hazel  was  on  his  own.  CDR  Griffin  and  LT  Perkins 
occasionally  asked  him  how  things  were  going. 

In  November  1986,  it  was  announced  that  OAIS  1.7 
would  be  implemented  in  March  1987. 

The  contractors  spent  most  of  the  fall  and  winter  of 
1986  converting  OAIS  code  from  JK  to  1.7.  The  code 
conversion  had  originally  been  planned  to  be  a  straight 
1 ine-for-line  conversion  in  view  of  the  design  standard  of 
upward  compatibility  between  different  versions  of  APSCOBOL. 
It  was  discovered  during  the  preliminary  testing  of  module 
integration  that  more  than  straight  line  conversion  was 
necessary.  Modules  had  to  be  completely  reworked  to  conform 
to  the  new  methods  of  how  the  programs  were  called  and  how 
transportation  from  screen  to  screen  was  handled.  The  new 
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version  of  APSCOBOL  required  more  overhead  due  to  the  logic 
changes  in  the  software.  Rewriting  the  logic  behind  the 
OAIS  screens  and  programs  was  time-consuming,  but  the 
advantages  of  more  efficient  code  outweighed  the  costs 
involved. 

Another  major  effort  was  the  development  of  test 
plans.  One  of  LT  Hopkins’  directives  after  the  May  1986 
failure  was  the  development  of  test  plans.  Test  plans  were 
written  by  SAGE  personnel  and  reviewed  by  Navy  personnel. 

LT  Hopkins,  CDR  Hazel  and  LT  Perkins  reviewed  the  plans  for 
the  Navy. 

In  February  1987,  SAGE  designated  V.  Hammer  as  the 
new  project  manager  for  OAIS.  She  had  previously  worked  on 
a  contract  dealing  with  the  Officer  Master  File  (OMF) ,  so 
she  had  some  experience  with  officer  systems. 

V.  Hammer  found  three  major  areas  needing  work  when 
she  took  over  the  project.  Two  of  these  areas  were  within 
OAIS.  One  was  converting  the  code  for  all  the  batch  jobs 
and  reports  and  verifying  the  Job  Control  Language  (JCL)  fcr 
each.  The  second  area  concerned  interface  testing  with  the 
applications  that  OAIS  provided  information  to.  Of 
particular  concern  were  the  interfaces  of  the  OMF,  MFS  and 
OPM. 

The  OPM  was  under  a  different  project  at  SAGE  as 
well  as  being  managed  by  a  separate  project  officer  for  the 
Navy  in  the  Information  Systems  Development  branch,  N470. 
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One  person,  Mr.  Donaldson,  was  working  on  the  OPM  when  V. 
Hammer  took  over  the  OAIS  project.  The  majority  of  work 
being  performed  by  Mr.  Donaldson  concerned  getting  the 
orders  through  the  Communication  Center  edits.  V.  Hammer 
immediately  went  to  her  boss  to  express  her  concern  over  the 
status  of  the  OPM  and  its  importance  to  the  OAIS  project, 
but  to  no  avail. 

V.  Hammer  set  her  personnel  to  working  on  the 
changes  needed  in  OAIS  reports.  She  worked  on  the  OMF 
interface,  having  knowledge  of  its  workings  from  her 
previous  project.  She  got  the  OMF  interface  error  rate  down 
to  about  five  percent,  a  much  lower  figure  than  the  current 
interface  between  OAIS  and  OMF. 

19 .  Conversion  Plans 

In  February,  the  Navy  decided  that  due  to  a  large 
amount  of  user  work  in  OAIS  JK,  they  could  not  just  take 
OAIS  down  and  replace  it  with  another  version  without 
causing  undue  hardship  to  the  users.  A  parallel  conversion 
was  decided  upon  and  SAGE  drew  up  conversion  plans.  V. 
Hammer  added  some  slack  time  to  the  estimation  of  effort  it 
would  take  to  do  the  conversion  in  order  to  give  OPM  testing 
more  time.  Up  to  this  point  the  OPM  had  failed  every  part 
of  the  test  plan  devised  for  it. 

The  implementation  date  for  OAIS  was  moved  from 
March  to  May  1987. 
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The  reasons  behind  the  push  for  production  of  OPM 
included  in-house  responsibility  for  order  generation 
instead  of  having  to  rely  on  NMPC-16,  and  having  officer  and 
enlisted  orders  in  the  same  format.  This  would  facilitate 
processing  at  the  Personnel  Support  Detachments  as  well  as 
providing  orders  to  military  personnel  that  they  could 
understand. 

2 0 .  Systems  Stress  Test 

In  late  February  1987,  a  systems  stress  test  was 
planned  to  test  how  the  newly  converted  software  code  worked 
with  the  hardware.  It  was  necessary  to  have  users  on  OAIS, 
both  so  the  Central  Processing  Unit  (CPU)  could  have  a  load 
and  to  test  the  interface  between  various  parts  of  the  new 
application,  particularly  those  interfacing  with  the 
orderwriting  module.  The  test  was  scheduled  from  1500-1530 
on  a  Friday. 

Production  OAIS  was  taken  off-line  during  the  test. 
Users  were  informed  by  OAIS  User  Bulletin  and  given  specific 
instructions  on  what  processes  to  carry  out.  User 
representatives  also  were  informed  at  an  OAIS  user  meeting. 
User  representatives  and  OAIS  Help  Desk  personnel  were 
available  in  the  user  spaces  for  assistance  and  for 
identification  of  problems.  Since  it  was  a  Friday,  there 
was  very  little  participation  by  the  users. 

A  second  stress  test  was  scheduled  for  a  Thursday 
afternoon.  CAPT  Williams  explicitly  requested  user 
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participation  at  the  weekly  department  head  meeting  with  the 
Admiral.  Procedures  were  as  before,  users  were  notified  by 
OAIS  User  Bulletin,  and  user  representatives  and  OAIS  Help 
Desk  personnel  were  in  user  spaces  for  assistance. 
Participation  was  much  better. 

21 .  Pre- implementation 

Testing  was  scheduled  to  last  for  six  weeks  starting 
in  March.  Testing  was  conducted  using  user  representatives 
and  experts  on  specific  portions  of  OAIS.  Testing  took 
place  in  the  training  roon  for  several  hours  each  afternoon 
during  the  month  of  April.  Washington  D.C.  experienced  a 
heat  wave  during  this  ti:  -  It  was  hot  and  stuffy  within 
the  unventilated  training  room.  The  test  plans  were  used  as 
a  guide  and  user  representatives  verified  that  menus, 
screens  and  procedures  worked  correctly.  Areas  that  worked 
correctly  were  signed  off  by  the  users.  Test  orders  were 
generated  and  used  to  test  the  OPM.  CDR  Hazel  and  LT 
Perkins  facilitated  the  testing  along  with  two  of  the 
contractors.  LT  Hopkins  looked  in  ^n  occasion.  TOAIS  was 
of  very  small  size,  holding  only  100  records,  a  small  number 
in  comparison  to  the  normal  70,000  records  of  active  duty 
officers.  Systems  personnel  were  assigned  to  monitor  TOAIS 
and  unlock  problems  before  they  brought  the  computer  system 
to  a  standstill.  At  the  end  of  each  session,  CDR  Hazel 
prioritized  problems  identified  with  the  concurrence  of  LT 
Perkins  and  the  contractors.  Priority  categories  were:  fix 
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before  implementation,  fix  within  a  few  weeks  of 
implementation  and  nice  to  have.  OAIS  seemed  to  work  fine. 
The  Order  Production  Module  was  not  quite  finished  during 
the  test  period,  but  bastardized  procedures  were  available. 
The  only  other  system  interface  which  was  tested  during  this 
time  with  the  OMF-OAIS  interface.  Preliminary  tests  showed 
no  problems. 

During  the  testing  phase,  more  personnel  were 
assigned  at  SAGE  to  work  on  the  OPM.  New  tests  still  showed 
that  the  OPM  did  not  work.  V.  Hammer  took  the  issue  to  her 
boss  once  again.  She  also  talked  to  LT  Hopkins  and  gave  her 
the  proof  of  failure  with  the  completed  and  unsuccessful 
test  plans.  LT  Hopkins  took  the  issue  to  her  boss,  CDR 
Rice,  who  ignored  the  proof  and  said  bring  up  OAIS  anyway. 

22 .  Training 

Some  training  for  user  representatives  was  conducted 
during  these  testing  sessions  by  LT  Perkins,  CDR  Hazel  and 
the  contractors.  Changes  to  the  orderwriting  module  were 
promulgated  through  a  new  version  of  the  OAIS  User  Manual. 
Training  on  a  large  scale  basis  for  all  users  was  not 
possible  due  to  the  nonavailability  of  TOAIS.  When  testing 
was  not  going  on,  the  contractors  required  use  of  the  TOAIS 
application  to  test  and  implement  software  fixes  to  problems 
identified  in  prior  testing  sessions.  LT  Perkins  hoped  that 
once  the  new  version  came  up,  that  the  individual  user 
representatives  would  help  train  the  personnel  in  their 


68 


departments  if  required.  The  idea  of  user  representatives 
assisting  personnel  in  their  departments  was  presented 
during  an  OAIS  user  meeting.  The  personnel  manning  the  OAIS 
Help  Desk  were  trained  through  participation  in  the  testing 
sessions  and  having  some  early  morning  access  to  TOAIS. 

Their  expertise  would  be  of  assistance  to  users  with  who  are 
unfamiliar  with  the  new  procedures. 

LT  Hopkins  coordinated  with  LT  Perkins  to  put  out  a 
series  of  OAIS  User  Bulletins  describing  some  of  the  new 
procedures.  The  plan  was  to  initiate  new  orders  and 
modifications  to  old  orders  on  the  new  version  and  to  use 
the  old  version  for  orders  still  within  the  chop  chain.  To 
ensure  proper  usage  of  the  new  version,  several  screens  in 
the  old  version  were  disabled.  Arrangements  were  made  with 
Scheduling  to  have  contractor  personnel  on  hand  for  at  least 
the  first  week  of  producing  orders  to  assist  the  scheduling 
personnel . 

LT  Hopkins  did  not  want  to  bring  up  OAIS  1.7.  There 
were  too  many  problems  with  the  OAIS-Order  Production  Module 
interface.  LT  Perkins  and  CDR  Hazel  also  felt  that  the  new 
version  was  not  ready.  They  were  very  familiar  with  the 
problems  existing  with  OAIS  through  their  participation  in 
the  testing.  Even  though  contractor  personnel  were  working 
overtime,  many  fixes  to  problems  discovered  during  testing 
had  not  yet  been  implemented.  CDR  Hazel  voiced  his  opinion 
at  a  branch  head  meeting  run  by  CAPT  Williams  and  attended 
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CDR  Rice 


by  the  branch  heads,  CDR  Rice,  and  CDR  Griffin, 
said,  "I  want  OAIS  operational  before  I  retire.  We  have 
been  advertising  that  it  would  come  up  for  six  months." 

23 .  OAIS  1.7  Chances 

The  majority  of  changes  revolved  around  the  new 
orderwriting  process  and  utilization  of  the  OPM  instead  of 
AUTONOM.  Some  of  the  changes  to  the  orderwriting  process 
included: 

Default  setting  for  mode  of  transmission  changed  from 
message  to  letter.  Orders  are  designated  as 
administrative  message  traffic  and  the  decision  was 
made  by  the  Admiral  that  unless  the  orders  were  to  be 
carried  out  in  30  days,  letter  was  the  designated  mode 
of  transmittal. 

On-line  help  with  order  format.  If  a  user  was  unsure 
about  what  order  format  to  use  on  a  particular  set  of 
orders  he  could  fill  in  just  the  first  digit  and  get  a 
list  of  all  formats  from  which  to  pick.  Also  if  a  user 
was  unsure  about  a  particular  text  to  put  in  a  set  of 
orders,  he/ she  could  call  up  all  the  text  and  read 
verbatim  what  would  be  printed  on  the  orders. 

Change  of  text  linkers  to  be  more  user  friendly.  Text 
linkers  are  used  to  designate  which  part  of  the  orders 
a  specific  text  applies  to  such  as  detaching, 
intermediate  or  ultimate.  In  OAIS  JK,  these  linkers 
were  letters  with  no  significance  to  the  user  as  they 
were  an  exact  copy  of  the  manual  document,  the  Officer 
Assignment  Document.  New  linkers  possessed  some 
natural  linkage  to  the  subject,  D  was  for  detaching, 
and  U  was  for  ultimate. 

Change  of  costing  information.  If  a  set  of  orders  was 
to  be  modified  in  OAIS  JK,  a  delta  figure  (plus  or 
minus)  was  incorporated  in  the  orders.  For  a 
modification  in  OAIS  1.7  the  amount  of  money  was 
entered  without  a  delta. 

-  A  system  was  designed  to  notify  a  order  writer  when  a 
UIC  included  in  the  orders  being  written  was  under 
minimize.  If  minimize  was  in  effect,  orders  had  to  go 
by  letter,  as  administrative  message  traffic  was  not 
allowed . 
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Incorporation  of  At  or  Near  Location  tables.  OAIS 
automatically  calculated  if  sites  for  training  or  the 
distance  between  two  duty  stations  were  close  enough 
together  to  be  costed  as  one  location.  Also  the  module 
automatically  costed  the  per  diem  costs  for  training, 
alleviating  detailers  of  this  chore. 

Changes  made  to  OAIS  included  the  following,  some  of 

which  had  been  user  requested: 

Query  by  Name  screen.  To  use  OAIS,  a  person's  social 
security  number  or  Activity  UIC  was  needed.  The  Query 
By  Name  screen  allowed  an  OAIS  user  to  enter  the  first 
seven  letters  of  an  officer's  last  name  and  OAIS  would 
provide  a  list  of  matching  personnel.  The  user  could 
then  select  the  one  desired. 

Addition  of  a  hold  facility  to  the  Action  Queue.  Quite 
often,  a  set  of  orders  is  ready  to  go  but  either  there 
is  no  one  identified  to  replace  the  officer,  or  there 
is  not  enough  money  to  send  the  orders.  Orders  that 
were  in  a  waiting  status,  caused  individual  assignment 
and  placement  officer's  action  queues  within  the  chop 
chain  to  grow  uncontrollable.  With  the  hold  facility, 
a  set  of  orders  could  be  designated  a  hold  and  moved 
off  the  action  queue  to  a  separate  hold  list. 

Upgrade  of  Security  Access.  Users  could  now  have  six 
desk  codes  identified  in  their  security  file,  to  which 
they  could  have  access.  This  access  was  available 
without  having  to  log  off  and  log  back  on  again  with  a 
different  User  Id.  This  upgrade  was  particularly 
useful  for  order  verifiers  who  worked  for  several 
assignment  officers.  Also,  when  a  user  went  on 
vacation,  access  would  be  available  to  his/her  desk 
code . 


F.  CASE  STUDY  FIVE 
1 .  Background 

NMPC-47  was  again  ready  to  implement  the  new  version 
of  OAIS  with  the  converted  code.  The  previous  try, 
approximately  a  year  ago,  had  ended  in  failure.  The  past 
year  had  been  spent  converting  the  code,  correcting  problems 
and  recoding  the  orderwriting  module.  Within  the 
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organization,  a  transition  from  a  development  to  a 
production  orientation  had  taken  place.  Responsibility  for 
production  OAIS  had  been  passed  to  the  Information  Systems 
Support  branch  and  resources  were  allocated  to  systems 
hardware  and  maintenance. 

2 .  Implementation 

The  big  day  came  on  a  Monday.  The  contractors,  LT 
Hopkins,  LT  Perkins,  and  CDR  Hazel  made  the  OAIS  Help  Desk 
their  headquarters  as  they  waited  for  the  calls  to  come  in. 
a .  Week  1 

The  first  type  of  problems  uncovered  had  to  do 
with  the  security  access  change.  Each  user  was  now  capable 
of  having  access  to  six  desk  codes  per  User  Id  instead  of 
one.  Users  had  been  told  of  this  upcoming  change  by  OAIS 
User  Bulletin  as  well  at  OAIS  User  meetings,  but  there  were 
people  who  had  not  gotten  in  their  paperwork  to 
Configuration  Management  to  change  their  security  profile. 

Most  of  the  other  problems  the  first  day 
involved  lack  of  training.  Calls  came  in  on  how  to  use  or 
update  a  screen.  The  first  sets  of  orders  under  the  new 
version  of  OAIS  went  out  by  message  on  Tuesday.  There  were 
13  of  them.  It  was  not  discovered  until  after  transmittal 
that  instead  of  having  a  From  of  Chief  of  Naval  Personnel, 
the  From  was  PERSUPPDET  Crystal  City.  The  PERSUPPDET 
Crystal  City  address  had  been  used  in  the  test  orders  and 
had  not  been  changed. 
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Orders  under  AUTONOM  usually  went  out 
approximately  24  hours  after  costing  had  approved  the 
orders.  During  the  first  weeks  of  OPM  processing,  orders 
were  held  up  for  several  days  due  to  bad  records  being 
passed  to  the  OPM.  The  philosophy  behind  OPM  development 
was  that  the  OPM  was  never  wrong.  Procedures  had  to  be 
devised  to  identify  bad  records  on  the  first  run  of  the  OPM, 
eliminate  them  and  rerun  the  OPM  until  there  were  no  bad 
records.  This  took  up  an  increasing  amount  of  each  night's 
processing  time.  Occasion  -ly,  work  was  not  accomplished 
before  it  was  time  to  bring  OAIS  up  in  the  morning. 

The  following  >roblems  caused  inconvenience  to 

the  users  and  needed  a  solution: 

A  problem  generated  by  the  conversion  process  made  95 
sets  of  orders  that  had  actually  errored  out  of  AUTONOM 
and  that  were  AUTONOM  rejects  look  like  they  had 
processed  successfully.  There  was  no  way  to  correct 
these  orders  in  either  version  for  a  few  days. 

Several  of  the  changes  implemented  in  OAIS  JK  were  not 
included  in  the  new  version. 

Automatic  chop  chain  routing  of  orders  to  coordinator 
review  and  subspeciality  when  the  orders  did  not 
require  the  edit. 

Every  set  of  orders  required  transferring  through  the 
Minimize  screen  within  the  orde  ^writing  menu,  even  when 
the  UICs  were  not  under  minimize. 

Due  to  the  orders  going  out  with  incorrect 
addressees,  CDR  Griffin  required  that  each  day's  orders  had 
to  be  reviewed  prior  to  release.  LT  Perkins  and  CDR  Hazel 
were  designated  as  the  reviewers.  Through  this  review 
process,  a  major  problem  was  discovered  with  aviation  duty 
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wording.  The  aviation  duty  wording  determines  flying  status 
and  pay  of  aviation  personnel.  Orders  were  going  out  with 
incorrect  flying  status  determination.  Looking  for  a  fix 
for  this  held  orders  up  for  three  days. 

A  Communication  Center  procedure  that  had  to  be 
kept  in  mind  when  holding  up  orders  was  that  the  Date-Time- 
Group  ( DTG)  on  the  orders  could  not  be  more  than  seven  days 
old. 

CDR  Hazel  and  V.  Hammer  finally  located  the 
cause  of  the  aviation  duty  wording  error  by  going  through 
the  code  line  by  line.  CDR  Hazel,  being  a  functional  expert 
on  order  specifics,  was  able  to  tell  V.  Hammer  what  was  to 
print  and  V.  Hammer  was  able  to  identify  the  errors  in  the 
code . 

The  first  week  of  OATS  1.7  ended.  All 
personnel,  contractors  and  Navy,  had  worked  long  hours  and 
were  exhausted,  but  the  new  version  of  OAIS  had  stayed  up 
for  a  whole  week,  which  was  better  than  the  last  time.  LT 
Hopkins  went  on  leave  for  three  weeks.  Her  boyfriend  was 
coming  back  from  a  six  month  deployment  on-board  a  ship, 
b.  Week  2 

More  problems  developed  with  orders  on  the 

second  week. 

One  hundred  thirty  sets  of  separation  orders  were  sent 
out  to  personnel  that  were  not  due  to  separate  from  the 
Navy. 

Duplicate  DTG's  were  discovered.  This  was  in  violation 
of  Communication  Center  procedure. 
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Missing  DTG's  were  discovered  in  the  course  of  routing 
hard  copy  orders  back  to  the  originating  assignment 
officer.  OAIS  showed  that  some  orders  went  out  on 
particular  personnel  with  an  assigned  DTG,  but  no  hard 
copy  was  ever  found.  Discovery  of  this  problem  changed 
the  procedures  involved  in  routing  of  hard  copy  orders. 

Previously,  Order  Support  branch  personnel  had 
just  sorted  orders,  keeping  a  copy  for  in-house  records. 

Now  they  were  required  to  verify  against  a  DTG  log  actual 
receipt  of  hard  copy  orders.  Missing  orders  were  passed  to 
LT  Perkins  who  had  been  delegated  liaison  with  the 
Communication  Center. 

Along  with  ownership  of  the  OPM  came 
responsibility  for  bad  magnetic  tapes.  Tapes  that  could  not 
be  read  by  the  Communication  Center  were  returned  to 
Scheduling  and  the  back-up  tape  submitted.  Occasionally 
part  of  a  tape  was  transmitted  and  in  order  not  to 
retransmit  messages,  a  violation  of  Communication  Center 
policy,  a  copy  of  the  partial  tape  had  to  be  made  by 
contractor  personnel. 

The  order  verification  process  was  made  even 
more  difficult  by  the  poor  quality  of  reports  provided  to 
the  OAIS  Help  Desk.  The  report  formats  were  just  copies  ' * 
the  old  reports  from  when  AUTONOM  and  NMPC-16  were 
responsible  for  order  tracking  and  verification.  Now  that 
NMPC-47  had  full  responsibility,  more  information  was  needed 
to  fulfill  this  job. 

The  change  in  the  default  value  of  the 
orderwriter  to  letter  versus  message  caused  a  steep  increase 
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in  the  number  of  orders  that  went  out  by  letter.  The 
sorting  machine  was  quite  old  and  acted  up  on  occasion. 

With  an  increase  in  workload,  the  machine  broke  down  at 
least  once  a  day  causing  a  letter  backup.  Letters  had  to  be 
sorted  manually  on  many  a  day  by  already-overworked 
personnel . 

From  the  first  try  at  generating  a  MFS  tape 
there  were  problems.  It  took  about  a  week  of  working  things 
out  between  NMPC  1 6  and  Naval  Finance  Center  in  Cleveland. 

It  wasn't  until  about  two  weeks  into  order  production  that 
the  accounting  problems  with  orders  were  discovered.  These 
problems  included: 

incorrect  rank  on  the  accounting  line. 

missing  accounting  lines  for  training  segments  of 
orders . 

incorrect  report  not  later  than,  report  no  earlier  than 
dates . 

accounting  data  for  training  was  printing  on  orders  not 
requiring  it. 

incorrect  information  in  the  at  or  near  location 
tables . 

Messages  and  questions  started  coming  in  from 
the  fleet  concerning  orders.  There  was  missing  activity 
text  for  certain  Personnel  Support  Detachments,  and 
misleading  text  for  some  orders  The  Communication  Center 
also  identified  problems  pertaining  to  the  Standard  Subject 
Identification  Code  (SSIC)  used  on  orders  messages  and  the 
use  of  asterisks  to  separate  portions  of  the  messages. 
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These  discrepancies  were  pointed  out  by  Communication 
Centers  in  the  field. 

The  Communication  Center  threatened  to 
discontinue  service  to  NMPC-47  on  several  occasions,  but 
that  threat  became  real  when  messages  were  transmitted 
starting  with  Date-Time-Groups  having  26  as  the  time.  The 
DTG  goes  on  a  24  hour  clock  and  there  is  no  such  thing  as  an 
hour  26. 

Minor  inconveniences  included  several  reports 
that  were  not  printing  and  the  Navy  Times  tape  not  being 
printed.  The  Navy  Times  tape  became  quite  an  issue  as  Navy 
Times  said  a  lot  of  their  readership  was  due  to  the  orders 
published  in  Navy  Times.  Contractor  time  needed  to  correct 
order  problems  was  diverted  to  the  Navy  Times  issue. 

During  the  second  week  of  crisis,  CDR  Hazel  and 
LT  Perkins  were  appointed  project  officers  in  LT  Hopkins' 
absence.  CDR  Hazel  dealt  with  OPM  fixes  and  telling  the 
contractor  what  to  do  as  they  were  of  first  priority.  LT 
Perkins  dealt  with  production  issues  such  as  liaison  with 
Scheduling,  Communication  Center,  order  production,  and 
fixing  OAIS  problems.  Upper  management  instituted  thrice 
weekly  status  meetings  with  SAGE,  CDR  Griffin,  LCDR  Wall,  LT 
Perkins,  CDR  Hazel,  and  some  of  the  technical  personnel  from 
both  SAGE  and  NMPC-47. 
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G.  CASE  STUDY  SIX 

1 .  Background 

NMPC-47  is  still  in  a  crisis  mode  due  to  the 
numerous  problems  with  OAIS  1.7.  OAIS  has  stayed 
operational,  but  at  the  expense  of  resources,  primarily 
contractor  overtime  and  NMPC-47  personnel. 

2 .  Aftermath  of  May  Failure 

Day-to-day  operations  revolved  around  daily  order 
production  and  retransmit al  of  orders  if  necessary.  Once  a 
day's  order  status  (orders  were  or  were  not  produced)  was 
known,  work  could  continue  on  fixing  trouble  reports  for  OPM 
and  OAIS.  The  number  of  manual  orders  having  to  be  typed  by 
Order  Support  branch  personnel  increased  from  a  daily 
average  of  five  to  75.  There  was  a  constant  backlog. 

This  crisis  mode  continued  through  the  summer.  LT 
Hopkins  returned  from  leave  and  was  told  she  was  not  to  get 
involved  with  the  production-oriented  part  of  OAIS.  In 
July,  SAGE  lost  the  OAIS  contract  to  another  contractor, 
SYSCCN . 

3 .  New  Contractor 

SYSCON  took  over  as  contractor  for  OAIS  in  August. 
SYSCON  was  familiar  with  the  workings  of  NMPC  as  they  were 
the  contractor  for  two  other  applications  within  NMPDS. 
Arrangements  were  made  for  the  turnover  of  source  libraries 
and  system  documentation  to  SYSCON.  NMPC-47  acted  as 
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intermediary,  as  there  were  hard  feelings  on  the  part  of 
SAGE  personnel. 

SAGE  personnel  involved  jith  the  OAIS  project  felt 
quite  bitter.  They  had  worked  overtime  all  summer  without 
any  breaks.  Blame  had  been  placed  at  their  feet  and 
everyone  was  calling  OAIS  a  disaster  when,  in  reality,  OAIS 
was  fine;  it  was  the  OPM-OAIS  interface  that  did  not  work. 
Work  on  OAIS  and  OPM  trouble  reports  virtually  came  to  a 
standstill  during  the  months  of  July  and  August. 

LT  Perkins  trained  the  SYSCON  personnel  on  the 
functional  purposes  of  OAIS  and  exposed  them  to  the  language 
of  the  assignment  and  placement  officers. 

SYSCON  did  an  initial  examination  of  the  order 
generation  problems.  A1;  the  time  they  saw  no  way  around  the 
quick  and  dirty  fixes  implemented  by  SAGE,  but  planned  for 
their  demise  in  the  near  future.  The  thoughts  of  NMPC-47 
management  were  those  of  starting  over  with  a  fresh  attitude 
and  management  style.  CDR  Griffin,  CDR  Hazel  and  LT  Perkins 
were  impressed  with  the  experience  that  Ms.  Green,  the 
project  manager  at  SYSCON,  brought  to  OAIS.  Initial 
meetings  with  her  consisted  of  honest,  and  in-depth 
explanations  for  OAIS  problems.  These  things  had  not  been 
forthcoming  from  SAGE  personnel.  Three  SYSCON  personnel 
were  assigned  to  rotate  staying  with  Scheduling  to  get 
orders  out  each  night. 
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Personnel 


4  . 

LT  Hopkins  was  moved  to  another  project  officer  job. 
A  junior  LT,  LT  Sanders  was  promoted  from  within  the  Surface 
Department  to  become  the  OAIS  Project  Officer.  LT  Sanders 
had  a  user’s  knowledge  of  OAIS,  but  did  not  have  a  computer 
or  software  development  background. 

LT  Perkins  and  CDR  Hazel  were  still  in  charge  of  OPM 
and  production  OAIS  issues,  but  LT  Sanders  was  to  get  the 
development  side  of  OAIS  on  the  move  again. 

CAPT  Hampton  relieved  CAPT  Williams  in  September 

1987 . 

5 .  Organization  Changes 

Several  changes  were  made  to  the  structure  of  the 
organization  after  CAPT  Hampton  arrived.  Order  Support  was 
moved  from  the  Order  Support  branch  to  the  Information 
Systems  Support  branch.  Scheduling  was  moved  out  of  Systems 
Administration  due  to  its  increasingly  important  part  of 
everyday  happenings.  The  Information  Systems  Support 
branch,  N471,  was  now  completely  customer  service  and 
production-oriented.  A  new  division  was  created  out  of  N472 
and  was  called  Information  Systems  Policy  and  Procedures. 

It  included  Configuration  Management  which  was  moved  out  of 
N47 1  and  Data  Administration  wnicL  was  moved  out  of  N470. 

See  Figure  5. 

Another  change  implemented  by  CAPT  Hampton  was  that 
training  was  mandatory  for  new  assignment  and  placement 
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NMPC  -  47 


Figure  5.  NMPC-47  Organization,  September  1987 


officers.  By  this  time,  there  were  two  modules  of  OAIS  and 
one  for  ODIS  of  computer-aided  training  developed  by  Oak 
Ridge  Associated  Universities.  The  computer-aided  training 
utilized  an  IBM  PC  XT  computer,  a  Pioneer  Laser  Disk  and  an 
ATI  touch  screen.  Training  was  provided  using  voice 


81 


synthesis  and  touch  screen  technology  that  was  interactive 
and  user  friendly. 

OAIS  user  meetings  became  mandatory  under  the 
direction  of  CAPT  Hampton.  Any  user  representative  not  in 
attendance  was  written  down  as  absent  in  the  weekly  user 
representative  meeting  minutes.  The  minutes  of  each  meeting 
were  published  as  dictated  by  CAPT  Hampton. 

6 .  Naval  Audit 

NMPC-47  received  notification  of  a  pending  Naval 
Audit  concerning  wasted  paper  due  to  unused  and  unwanted 
OAIS  reports. 

7 .  OAIS  Development  versus  OAIS  Production 

The  initial  division  of  labor  at  SYSCON  was  three 
contractors  working  on  production  trouble  reports  with  LT 
Perkins  in  charge  and  three  contractors  working  on 
development  and  necessary  changes  with  LT  Sanders  in  charge. 

Two  of  these  necessary  changes  were  the  addition  of 
several  data  elements  to  the  Activity  File,  one  of  the  major 
applications  OAIS  interfaces  with  and  implementation  of  the 
Joint  Specialty  Designation  and  its  associated  tracking/ 
chopping  of  orders  which  had  been  approved  by  Congress. 

These  changes  to  the  Activity  File  by  EPMAC  also 
involved  moving  the  location  of  several  data  elements  within 
the  file.  Plans  were  made  for  the  change.  SYSCON  and  LT 
Sanders  spent  an  entire  weekend  of  computer  and  contractor 
time  trying  to  implement  the  change  without  success.  LT 


82 


Perkins  was  not  included  in  their  plans  even  though  she  was 
an  expert  on  OAIS.  After  the  unsuccessful  weekend,  CDR 
Griffin  and  LCDR  Wall  decided  to  put  off  any  development 
changes  for  several  months.  They  decided  that  LT  Sanders 
needed  to  learn  more  about  OAIS  and  NMPC-47  operations. 

A  problem  uncovered  during  the  implementation  of 
this  change  was  the  inadequate  and  old  OAIS  documentation. 
One  of  the  reasons  there  were  problems  with  the 
implementation  was  because  the  documentation  was  incorrect. 

LT  Perkins  was  in  charge  of  all  OAIS  production- 
oriented  work  and  had  all  six  programmers  working  on 
production  changes.  CDR  Griffin  and  LCDR  Wall  hoped  that 
with  all  the  time  spent  on  production  problems  that  some 
progress  on  long  standing  OAIS  problems  could  be  made.  Of 
particular  importance  was  the  problem  with  the  PRD  data 
element.  Assignment  officers  would  update  an  officer's  PRD 
and  due  to  problems  with  the  Officer  Master  File  interface, 
the  change  would  not  reflect  in  the  Officer  Master  File  and 
the  PRD  would  change  back  to  its  previous  value  in  OAIS. 

8 .  Production  Changes 

Plans  were  made  and  progress  continued  toward  having 
the  Navy  personnel  in  Scheduling  be  the  ones  running  the 
batch  updates  and  order  generation  at  night. 

A  policy  was  implemented  by  CDR  Griffin  that 
whenever  a  fix  was  put  into  OPM  or  OAIS,  a  SYSCON  person 
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would  be  in  Scheduling  that  evening  to  ensure  that  no 
problems  were  encountered. 

Another  change  was  that  all  trouble  reports  were 
prioritized  by  LT  Perkins.  LT  Perkins  maintained  a  daily 
status  of  the  progress  made  on  individual  trouble  reports. 
User  representatives  were  kept  informed  by  weekly,  mandatory 
OAIS  meetings. 

LT  Perkins  instigated  a  policy  of  having  the  Navy 
test  all  software  fixes  c,  inerated  by  SYSCON.  LT  Perkins 
delegated  most  of  the  test  *ng  to  her  personnel  at  the  OAIS 
Help  Desk.  Involving  the  i^lp  desk  personnel  in  the  testing 
and  scheduling  of  softwa^^  changes  increased  their  morale. 

If  it  was  a  top  priority  trouble  report  she  would  also  test 
the  fix  herself. 

LT  Perkins  preferred  to  implement  the  OAIS  changes 
in  the  afternoon,  preferably  on  a  Wednesday  or  Thursday,  so 
that  the  change  would  be  available  first  thing  in  the 
morning.  User  representatives  were  informed  of  the 
implementation  schedule  at  the  weekly  meetings.  If  a 
problem  was  discovered  with  the  fix,  it  could  be  pulled  out 
with  only  an  hour  of  downtime.  Thursdays  and  Fridays  were 
usually  slow  for  the  users  as  the  majority  of  their  workload 
was  accomplished  in  the  early  part  of  the  week.  These  days 
also  were  slow  days  for  Scheduling.  They  were  usually 
caught  up  on  batch  jobs  and  had  some  spare  time,  which  was 
needed  in  case  a  problem  arose. 
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With  Scheduling  of  more  importance,  several  problems 
came  to  the  forefront.  Actually  they  had  been  problems  for 
a  long  time,  but  never  made  it  to  the  limelight.  These 
included  problems  with  non-standard  run  books  and  program 
naming  conventions.  The  solutions  were  worked  out  with  the 
Configuration  Control  Board  (CCB) ,  Configuration  Management 
and  SYSCON.  These  standards  wouid  be  incorporated  in  any 
new  development  or  software  fix.  The  CCB  also  decided  that 
a  period  of  review  prior  to  implementation  of  a  fix  to 
ensure  compliance  with  run  book  and  adherence  to  standards 
would  be  implemented. 

Report  distribution  problems  were  also  noticed. 

With  the  OAIS  1.7  implementation,  several  reports  were  not 
printing,  some  reports  were  printing  incorrect  information 
and  there  were  now  unwanted  reports  requested  by  personnel 
who  had  left  NMPC.  Report  trouble  reports  had  been  given 
low  priority  during  the  summer,  but  with  a  Naval  Audit  being 
conducted,  one  of  the  junior  programmers  at  SYSCON  was 
assigned  to  fix  all  the  report  trouble  reports. 

CDR  Hazel  instituted  a  new  policy  with  respect  to 
trouble  reports  for  the  OPM.  He  required  a  requirements 
analysis  be  completed  prior  to  submission  of  a  trouble 
report  to  the  contractors.  This  analysis  would  assist  in 
establishing  OPM  documentation. 
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9 .  OAIS  User  Participation 

For  those  trouble  reports  not  identified  as  top 
priority,  user  representative  input  was  taken  on  where  they 
should  fall  in  the  priority  scheme.  LT  Sanders  was  getting 
the  paperwork  side  of  the  OAIS  development  in  order.  She 
collected  approximately  200  SCP's  that  had  been  submitted 
over  the  past  three  years.  Records  had  not  been  maintained 
very  well  and  she  was  not  sure  if  some  of  the  changes  had 
already  been  implemented.  User  representatives  were  asked 
to  vote  on  the  priority  of  SCP's  for  development.  When  a 
software  fix  to  OAIS  involved  a  specific  procedure  for  a 
group  of  users,  the  applicable  users  would  be  asked  to  test 
the  fix  before  it  went  into  production. 

10 .  NMPDS  Planninq/Intearat ion 

A  Configuration  Control  Board  (CCB)  was  established 
in  NMPC-47.  Members  included  branch  heads,  Data 
Administration,  Configuration  Management,  Systems 
Administration,  Scheduling,  project  officers  and  help  desk 
personnel.  The  purpose  of  the  CCB  was  to  review  plans  and 
changes  to  all  four  applications  under  the  NMPDS  umbrella. 
The  plan  was  to  ensure  compatibility  of  all  the  applications 
under  NMPDS  for  future  integration  and  resource  sharing. 

All  software  fixes  and  a  plan  for  implementing  the  fix  were 
routed  around  to  various  members  of  the  CCB  for  signoff 
before  the  weekly  scheduled  meeting. 
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At  the  weekly  scheduled  meeting,  the  initiator  of 
the  trouble  report,  usually  LT  Perkins,  briefed  the  board 
members  as  necessary  and  advised  them  on  the  schedule  for 
implementation.  SYSCON  was  also  invited  to  CCB's  on  an  as- 
required  basis.  Their  role  was  usually  to  explain  a  long 
range  plan  for  correction  of  a  problem. 

11 .  Electronic  Mail  Usage 

CAPT  Hampton  believed  in  the  electronic  mail  system. 
He  ensured  command  usage  of  electronic  mail  within  NMPC-47 
by  sending  out  all  his  messages  to  the  branch  heads  on  it. 
With  top-down  support,  the  branch  heads  implemented 
electronic  mail  into  their  routines.  Usage  traveled  further 
down  the  chain  of  command  until  every  manager  made  sure  they 
read  their  mail  everyday. 

By  late  November,  the  major  problems  with  the  OPM 
were  solved.  The  quick  and  dirty  programs  were  still  in 
place  because  replacements  for  them  were  quite  involved. 

Some  development  efforts  were  started.  OAIS  users  had 
settled  down  having  seen  affirmative  action  and  improvements 
with  new  procedures. 
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IV.  ANALYSIS 


A.  INTRODUCTION 

This  chapter  analyzes  each  of  the  six  case  studies. 
Section  One  contains  questions  which  can  be  used  for  two 
purposes:  to  help  a  student  prepare  the  case  or  to  lead  off 
questions  for  a  class  discussion.  Section  Two  is  a  summary 
of  the  case  study.  Section  Three  lists  the  major  issues  or 
problems  that  the  case  study  deals  with.  Identification  of 
these  issues  links  potential  lecture  material  with  the  case. 
Section  IV  is  the  case  analysis  in  which  theories  pertinent 
to  the  case  are  discussed  and  the  particular  facts  of  the 
case  are  related  to  the  theory. 

One  specific  area  of  analysis  which  will  be  included  in 
all  six  cases  is  Nolan's  Stages  of  Growth  Model  [Ref.  ll:pp. 
672-673].  Nolan  has  researched  information  systems 
development  throughout  many  organizations.  His  research 
involved  the  monitoring  of  information  systems  investments, 
information  systems  budgets,  types  of  applications  being 
developed,  and  the  degree  of  management  control  and  planning 
utilized.  By  looking  at  these  factors  he  noticed  definite 
shifts  in  the  direction  and  growth  of  the  information 
systems.  He  developed  a  model  covering  six  stages  of  growth 
of  both  the  information  systems  and  the  management  of  the 
information  systems.  Not  every  organization  or  information 
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system  passes  through  all  of  these  phases,  but  they  are  a 
good  indication  of  possible  directions  for  the  future.  This 
model  can  assist  an  information  systems  department  to 
evaluate  its  present  and  future  decisions  in  comparison  with 
basic  indicators  of  growth.  See  Figure  6.  Throughout  the 
case  series,  the  stage  or  stages  that  NMPC-47  is  in  will  be 
identified  and  discussed.  [Ref.  ll:pp.  672-673] 


Nolan's  Stages  of  Growth  Model 


TIME  (experience  in  in  formation  systems  aeveiopment  and  usage) 


Figure  6.  Nolan's  Stages  of  Growth  Model 
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B.  CASE  STUDY  ONE  TEACHING  NOTE 


1 .  Questions 

What  problems  do  you  anticipate  with  the  development 
and  implementation  of  the  management  information 
system? 

What  was  done  well  in  the  development  and 
implementation? 

What  affects  do  you  think  implementation  of  the 
prototype  will  have  on  the  Life  Cycle  Management  of 
OAIS? 

2 .  Case  Summary 

This  part  of  the  case  series  provides  the  background 
concerning  the  establishme  -  of  the  Officer  Assignment 
Information  System  (OAIS) .  Descriptions  of  the  users,  user 
requirements,  command  mil  .on,  and  OAIS  requirements  are 
discussed.  The  development  methodology  chosen  for  OAIS 
development  was  prototyping.  The  software  utilized  was 
Application  Productivity  System  (APS) COBOL,  a  third 
generation  language.  NMPC-47  was  on  the  leading  edge  of 
technology  by  utilizing  prototyping  versus  the  traditional 
development  approach.  The  initial  deployment  of  OAIS,  the 
problems  encountered  throughout  the  user  organization,  and 
the  improvements  OAIS  made  in  a  previously  manual  assignment 
process  are  described. 

3 .  Manor  Issues/Problems 

Use  of  prototyping  development  methodology  and  a  new 
generation  of  software. 

Deployment  of  the  prototype  due  to  user  dependence. 

Poor  documentation. 
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Lack  of  pre-implementation  activities  for  the 
application  and  the  effects  on  the  users. 

4 .  Case  Analysis 

a.  Nolan's  Stages  of  Growth 

Stage  one  is  called  Start  Up.  This  stage  begins 
with  the  first  computer  acquisition  of  an  organization.  In 
this  stage  the  computer  is  being  utilized  for  general  and 
administrative  projects  whose  automation  would  result  in 
cost  savings.  There  is  quite  a  bit  of  change;  change  in 
jobs  and  working  habits  and  fear  of  the  unknown.  [Ref. 
ll:p.  672] 

NMPC-47  has  just  entered  the  Start  Up  stage. 

The  assignment  process  is  one  r'  an  administrative  nature. 
The  first  computer  has  not  even  been  procured  and  a  leasing 
arrangement  is  providing  the  computing  power.  Personnel 
within  the  computer  organization  who  are  used  to  manual 
methods  and  potential  users  of  the  system  are  resisting  the 
change  and  fearing  the  unknown. 

b.  Prototyping  Methodology 

Prototyping  is  a  devel  'ment  methodology  that 
enables  the  developer  of  a  computer  application  to  create  a 
working  model  of  the  software  to  be  built  [Ref.  12:p.  22]. 
Prototyping  is  used  in  cases  where  the  speed  of  implementa¬ 
tion  of  the  computer  application  is  of  the  essence  and/or 
where  the  users  are  unable  to  specify  explicitly  what  they 
want  the  system  to  do.  Good  potential  computer  application 
candidates  for  use  of  the  prototyping  methodology  include; 
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those  where  the  user  is  concerned  about  screen  format,  where 
the  system  will  be  on-line,  where  there  are  very  few 
algorithmic  details,  and  the  system  utilization  is  for  ad 
hoc  retrieval  or  record  management  [Ref.  13 :p.  61].  The 
prototyping  takes  the  place  of  requirements  definition  in 
the  traditional  classical  project  life  cycle  development 
methodology. 

The  prototyping  steps  are  as  follows:  (1) 

identify  the  user's  known  information  requirements;  (2) 
develop  a  working  model;  (3)  have  rhe  users  use  the  system 
in  a  "hand's  on"  manner  and  note  user  requests  for  changes; 
and  (4)  refine  or  expand  user  requirements  through 
development  of  another  model  [Ref.  ll:p.  6121.  This  process 
is  iterative  and  continues  until  the  user  is  satisfied  with 
the  working  prototype.  Not  only  does  the  user  clarify  his 
requirements  for  the  computer  application,  but  the  developer 
of  the  system  also  receives  a  clearer  picture  of  what  needs 
to  be  done  [Ref.  12:p.  23].  One  problem  that  has  been 
identified  with  prototyping  is  the  tendency  of  users  to 
accept  a  premature  prototype.  A  major  factor  contributing 
to  this  is  dissatisfaction  with  the  current  system  [Ref. 

14 : p.  2]. 

The  assumption  within  the  prototyping 
methodology  is  that  once  the  users  are  satisfied  with  the 
prototype,  the  model  will  be  thrown  away  and  replaced  with 
real  programs  by  following  the  design,  code,  test  and 
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implementation  steps  of  the  traditional  development 
methodology  [Ref.  13:p.  61].  The  reasons  for  throwing  away 
the  working  model  are  as  follows:  The  emphasis  of  the 
prototyping  method  is  on  the  output,  not  how  the  output  is 
produced  [Ref.  ll:p.  612].  This  emphasis  on  the  output 
combined  with  the  fact  that  the  developer  is  working  under  a 
time  constraint  leads  to  the  pcssibility  of  compromises  in 
tne  implementation  of  the  inner  workings  of  the  model.  Such 
things  as  error  recovery,  audit  trails,  backup/restart 
facilities,  user  and  system  documentation  and  conversion 
procedures  may  be  glossed  over  [Ref.  13 :p.  62].  An 
inefficient  algorithm  may  be  incorporated  or  an  inappropri¬ 
ate  operating  system  may  be  utilized  all  in  the  interest  of 
time  and  output  [Ref.  12 :p.  23].  Factors  which  affect  the 
life  cycle  of  the  computer  system  such  as  overall  software 
quality,  and  long  term  maintainability  may  not  be  considered 
[Ref.  12 : p .  23]. 

The  decision  to  use  the  prototyping  methodology 
at  NMPC  was  an  excellent  one.  Problems  with  the  manual 
assignment  process  had  been  discussed  for  several  years.  Of 
particular  significance  was  the  amount  of  time  it  took  to 
process  an  individual  officer's  assignment.  Each  assignment 
took  approximately  four  to  five  weeks  to  get  approval.  The 
assignment  then  had  to  be  manually  costed  and  typed  before 
transmission  to  the  officer.  Other  problems  included 
officer  information  existing  in  different  files  within 


93 


different  computer  systems  in  NMPC-16,  accuracy  of  the  data, 
inaccurate  reporting  instructions  on  moves,  and  inability  to 
consider  a  large  pool  of  possible  assignments.  Since  the 
users  were  a  diverse  group,  with  the  manual  assignment 
process  being  adapted  differently  for  each  department 
(Aviation,  Submarine,  and  Surface) ,  NMPC-47  was  unsure 
exactly  what  the  user  requirements  were.  Additionally,  due 
to  the  timeframe  of  development,  the  early  1980's,  problems 
with  the  traditional  life  cycle  development  were  coming  to 
light.  Cost  overruns,  schedule  delays,  and  computer  systems 
not  meeting  user  requirements  characterized  the  current 
state  of  the  industry.  The  prototype  was  developed  and 
users  from  the  Surface  Department  helped  refine  the  working 
model . 

c.  Selection  of  Software 

APSCOBOL,  a  product  still  under  development,  was 
chosen  as  the  software  for  OAIS .  The  Application 
Productivity  System  portion  consisted  of  an  application 
generation  tool  which  would  interface  well  with  the 
prototyping  methodology.  Application  generators  are 
software  programs  that  permit  specification  of  an  entire 
application  at  a  high  level  without  having  to  be  concerned 
with  the  coding  of  each  line  cf  code.  The  application 
generator  produces  the  source  code  based  upon  the 
specifications  [Ref.  ll:p.  254].  It  can  also  allow  a  junior 
programmer  to  produce  sophisticated  code  after  just  a  few 
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weeks  of  training.  Other  tools  included  a  screen  painter 
and  report  generator.  A  screen  painter  allows  easier 
configuration  of  a  data  formatted  screen.  Additional 
benefits  are  ease  of  change  and  proper  spacing  for  ease  of 
use.  A  report  generator  assists  the  extraction  of  data  for 
reports  from  specific  files.  These  tools  can  speed  up  the 
production  of  code. 

Of  particular  importance  to  NMPC  and  the 
prototyping  methodology  was  the  portability  of  APSCOBOL 
between  different  types  of  hardware.  By  using  APSCOBOL,  a 
prototype  could  be  developed  during  the  hardware  procurement 
process  with  the  knowledge  that  whatever  hardware  was 
purchased,  the  prototype  would  be  able  to  function  on  it. 
There  was  definite  risk  taken  by  NMPC  by  using  the  first 
version  of  APSCOBOL.  It  is  a  notorious  fact  that  the 
original  version  of  most  any  piece  of  software  contains  bugs 
and  it  is  safer  to  wait  for  the  next  version,  where  the  bugs 
have  been  corrected. 

d.  Deployment  of  the  Prototype 

The  prototype  vastly  improved  the  assignment 
process.  Users  became  so  dependent  on  the  system  that  when 
it  was  time  for  the  developers  to  take  the  working  model  and 
finish  the  rest  of  the  development  steps,  NMPC-47  management 
gave  into  user  pressure  for  immediate  implementation  of 
OATS . 
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The  tendency  to  implement  the  prototype  is  a 
strong  and  dangerous  one  [Ref.  13 :p.  63].  Problems  that 
this  will  cause  cover  both  the  immediate  and  long  term  life 
cycle  management  activities.  Recall  that  prototype  emphasis 
is  on  the  output,  not  the  internal  workings  of  the  system. 
Inefficient  algorithms,  error  handling  procedures, 
inadequate  interfaces  with  other  systems,  and  poor  user 
documentation  are  a  few  of  the  possible  immediate  problems. 
In  the  long  term,  maintenance  and  modification  of  the  system 
will  be  difficult.  Inefficient  use  of  computer  resources 
will  come  into  play,  incomplete  system  documentation  will 
make  incorporation  of  changes  frustrating  and  the  changes 
will  take  a  longer  period  of  time  [Ref.  14 :p.  2].  Of 
particular  note  are  changes  desired  by  the  second  generation 
of  users  [Ref.  13:p.  63].  Second  generation  users  are  those 
users  not  around  to  see  the  vast  difference  between  the 
manual  system  and  the  automated  system.  Changes  requested 
by  these  users  will  most  likely  be  handled  by  second 
generation  developers  who  are  not  as  familiar  with  the  code 
and  appropriate  reasons  for  handling  certain  situations  as 
they  are. 

To  guard  against  implementation  of  the 
prototype,  project  management  should  state  at  the  start  of 
the  project  what  the  development  procedures  will  be  [Ref. 
14:p.  2].  By  providing  this  guideline  and  educating  the 
users  as  to  the  benefits  of  proper  design,  test  and 
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implementation,  a  better  computer  system,  in  both  the  short 
and  long  term,  is  possible. 

Problems  with  implementation  of  the  prototype 
first  became  evident  as  OAIS  was  implemented  in  the  Aviation 
and  Submarine  Departments.  The  lack  of  user  documentation 
caused  OAIS  utilization  problems.  Training  is  an  integral 
part  of  the  implementation  procedures  for  a  computer 
application.  Users  that  are  not  prepared  beforehand  with 
training  and  user  documentation  are  soon  frustrated  and 
often  times  do  not  use  the  application.  There  had  been  no 
problem  with  OAIS  within  the  Surface  Department  due  to  their 
working  knowledge  of  the  system  which  was  acquired  during 
their  assistance  with  development.  A  training  officer 
billet  was  established  and  filled  in  the  summer  of  1984. 

The  first  user's  manual  was  produced  in  January  1985,  over 
two  years  after  the  implementation  of  the  prototype, 
e.  Poor  Documentation 

One  of  the  problems  cau  1  by  implementation  of 
the  prototype  is  the  poor  quality  or  lack  of  documentation. 
The  following  has  been  noted  from  <  report  prepared  by 
SYSCON  corporation  concerning  documentation  efforts  in 
prototyping  efforts: 

...formal  written  documentation  takes  a  poor  second  to  the 
exciting,  more  visual  simulation  of  new  prototype 
software.  Often,  by  the  time  it  is  understood  how  badly 
good,  careful  documentation  is  needed,  the  people  who 
could  write  it  best  are  gone.  [Ref.  15:p.  5] 

Without  documented  requirements,  interpretation  replaces 
detailed  definition.  Developers  interpret  users'  stated 
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requirements.  Subsequent  modification  to  functionality  is 
interpreted  by  new  users'  in  relation  to  the  operating 
software  system.  The  process  moves  ever  further  from 
objective  to  subjective.  [Ref.  15:p.  5] 

The  lack  of  user  documentation  and  its  effects 
have  already  been  discussed.  Modifications  and  enhancements 
have  not  occurred  to  OAIS  yet,  but  it  is  fairly  safe  to  • 
predict  that  problems  will  occur  due  to  a  lack  of  system 
documentation  and  updated  system  requirements. 

f.  Suggested  Pre-Implementation  Activities 

Any  change  within  an  organization  needs  to  be 
planned  for  and  managed  closely.  Individuals  resist  change 
for  a  variety  of  reasons.  These  reasons  include  fear  of  the 
unknown,  avoidance  of  uncertainty,  additional  pressures  and 
loss  of  individual  security  [Ref.  9:p.  37].  Past  ways  of 
doing  business,  daily  habits  and  routines  are  a  part  of  an 
individual's  security  because  they  are  predictable.  There 
is  a  loss  oi  che  prior  "comfort  zone,"  which  contributes  to 
an  individual's  sense  of  values  and  view  of  themselves  [Ref. 
9:  p.  163]. 

Two  criteria  are  recommended  for  minimizing 
resistance  to  change.  These  are  education  of  personnel  and 
user  participation  in  the  planning  and  decision  process 
[Ref.  16:pp.  94-95].  Education  of  personnel  establishes 
effective  lines  of  communicatxon  and  decreases  speculation 
and  rumors.  The  longer  personnel  have  to  speculate  about  an 
upcoming  change,  without  being  provided  official 
information,  the  more  likely  it  is  that  resistance  will 
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emerge  [Ref.  9:p.  163],  Having  open  lines  of  communication 
gives  personnel  someone  to  go  to  with  questions  and 
concerns.  Education  provided  to  individuals  should  include 
schedules,  plans,  both  short  and  long  term,  and  their 
probable  consequences  [Ref.  16:pp.  94-95]. 

It  is  more  likely  that  acceptance  of  the  change, 
as  well  as  an  assurance  of  the  application  meeting  user 
needs,  will  be  accomplished  by  involving  personnel  in  the 
planning  process.  Personnel  that  are  involved  are  more 
likely  to  display  interest  and  feel  a  sense  of  ownership. 
This  is  likely  to  lead  to  increased  motivation  and 
understanding  [Ref.  9:p.  163].  Additionally,  in  a  sense, 
management  has  added  people  to  its  point  of  view  for  the 
need  and  understanding  for  change.  Personnel  involved  with 
the  change  can  spread  good  information,  not  rumor,  among 
fellow  workers. 

In  addition  to  education  of  users,  all  levels  of 
management  should  be  made  aware  of  the  upcoming  changes 
[Ref.  16:p.  132].  This  awareness  will  increase  both  support 
of  the  new  idea  and  perhaps  bring  out  possible  loopholes 
missed  up  to  this  point.  With  all  management  levels 
speaking  the  party  line  and  understanding  the  reasons  for 
change,  increased  acceptance  will  be  the  benefit. 

An  organization  is  composed  of  flows  of 
information,  personnel  and  material  [Ref.  9:p.  29].  The 
implementation  of  OAIS  affected  all  three  of  these  factors. 
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The  flow  of  information  went  from  manual  to  automated.  The 


personnel  interacted  with  throughout  the  course  of  a 
business  day  changed  as  well  as  how  the  material  was 
produced.  Different  material  was  also  produced.  Automated 
reports,  one  of  the  outputs  of  OAIS,  were  now  sources  of 
information . 

Taking  into  consideration  the  two  criteria 
useful  in  minimizing  resistance  to  change;  there  was 
participation  of  some  users  (all  from  the  Surface 
Department)  in  the  decision  making  and  modeling  of  the 
prototype,  but  no  education  of  current  or  future  users. 

This  participation  in  the  prototyping  process  did  foster  a 
sense  of  ownership  and  additional  motivation  within  the 
users.  Training  was  not  necessary  for  these  personnel. 

This  first  implementation  in  the  Surface  Department  set  a 
bad  precedent  for  NMPC-47  management  and  created  a  false 
sense  of  security. 

It  was  not  until  basic  problems  with  using  OAIS 
were  discovered  upon  subsequent  implementations  that 
management  realized  education  of  users  was  a  necessity.  In 
addition,  the  lack  of  education  for  the  personnel  in  the 
Information  Systems  Support  branch  and  Order  Support  branch 
concerning  the  department’s  changing  direction  was  a 
deterrent  to  acceptance  of  change.  Information  Systems 
Support  branch  personnel  were  busy  maintaining  the  current 
manually-oriented  systems.  They  were  not  consulted  on  the 
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details  of  the  new  systems,  nor  invited  to  meetings.  These 
were  the  people  familiar  with  the  systems  which  would 
interface  with  OAIS  as  well  as  those  with  the  intimate 
knowledge  on  order  writing,  the  primary  objective  of  OAIS. 
Without  their  support  and  indeed  the  criticism  they  heaped 
on  OAIS,  the  resistance  of  the  users  who  still  interfaced 
with  these  personnel  grew. 

After  implementation  of  OAIS,  many  users 
continued  in  their  manual-oriented  routine  patterns  of 
decision  making,  order  verification  and  interface  with 
personnel  in  the  assignment  process  chop  chain.  If  top 
management  within  the  division  such  as  the  Submarine 
Department,  took  an  active  interest,  it  was  more  likely  that 
OAIS  use  replaced  some  manual  work.  One  user  had  not  even 
turned  the  computer  on.  It  was  not  until  individual 
attention  was  paid  to  each  person  or  group,  that  grudging 
acceptance  came.  "Tender  loving  care"  was  called  for  to  get 
past  the  resistance  and  onto  understanding  and  comfort  with 
OAIS.  This  was  accomplished  by  establishment  of  a  training 
officer  billet.  Establishment  of  this  function  was  a 
reaction  instead  of  a  planned  event.  If  training  of  users 
had  been  planned  upfront  along  with  the  software  development 
and  hardware  procurement,  OAIS  acceptance  would  have 
happened  much  quicker  within  the  command. 
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C.  CASE  STUDY  TWO  TEACHING  NOTE 

1 .  Questions 

Does  project  management  work  well  with  this 
organization  structure?  Why  or  why  not?  What  changes 
would  you  recommend? 

Are  you  satisfied  with  LT  Hopkins'  management  of  the 
OAIS  project? 

Is  the  new  version  of  OAIS  going  to  work  properly?  Why 
or  why  not? 

2 .  Case  Summary 

This  case  addresses  the  timeframe  of  October  1985 
through  May  1986  for  activ  ties  within  NMPC-47.  A  new 
project  officer  for  OAIS  has  just  taken  over  the  project. 
Personnel  changes  are  al<  -  taking  place  within  the 
contractor's  OAIS  project  staff.  The  primary  activity 
during  this  time  is  development  of  a  new  version  of  OAIS. 

The  major  changes  involved  are  conversion  of  the  software 
from  the  original  version  of  APSCOBOL  to  a  new  version,  1.7, 
and  a  newly  designed  orderwriting  module.  The  team  of 
personnel  responsible  for  tnis  new  version  is  a  combination 
of  contractor  and  Navy  Data  Processing  Technicians. 

3 .  Major  Issues/Problems 

Implementation  of  matrix  structure  on  organization. 

New  project  officer  and  project  officer  style  of 
management. 

Heavy  reliance  on  contractors. 

OAIS  development  team  combination  of  contractor  and 
Navy  personnel. 

Lack  of  planning  for  pre-implementation  activities. 
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4 .  Case  Analysis 

a.  Nolan's  Stages  of  Growth 

NMPC-47  has  moved  up  the  growth  curve  with  its 
evolving  computer  application.  The  changes  to  OAIS  put  NMPC 
in  the  Growth  of  Information  Systems  stage.  Characteristics 
of  this  stage  are  having  the  excess  computer  capacity 
characteristic  of  the  Start  Lp  pnase  being  used  up  quickly, 
and  making  investments  in  additional  hardware  and  software. 
This  contagious  enthusiasm  of  users  and  computer  personnel 
results  in  uncontrolled  growth.  OAIS  users  have  become 
somewhat  sophisticated  in  usage  of  the  application  and  have 
requested  enhancements.  The  Systems  Administration  division 
has  just  received  its  first  computer  and  additional 
peripheral  equipment  is  on  the  way.  [Ref.  ll:pp.  672-673] 

b.  Project  Management 

Project  Management  is  ar  ongoing  process 
throughout  the  life  cycle  of  a  computer  application  by  which 
a  team  leader  (project  officer)  directs  the  team  in  the 
development  of  an  acceptable  syster:  *hich  meets  user 
requirements  and  that  is  produced  within  the  allotted  time 
and  budget  constraints  [Ref.  17:p.  161].  Directing  the  team 
involves  using  the  basic  management  functions  of  planning, 
organizing,  directing  and  controlling.  The  key  concept 
underlying  project  management  is  that  the  project  officer  is 
the  single  point  of  integrative  responsibility  between  all 
project  team  members  [Ref.  18:p.  4]. 
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In  the  OAIS  project,  the  development  team  would 
consist  of  the  contractors,  the  Navy  Data  Processing 
Technicians  in  the  Application  Programming  Shop,  the 
Training  Officer  in  N470,  and  the  various  functional 
managers  such  as  Systems  Administration,  Data  Administration 
and  Configuration  Management.  The  integration  of  all  of 
these  faction's  efforts  towards  development  of  a  new  version 
of  OAIS  is  LT  Hopkins'  primary  task. 

Project  Officers'  view  project  management  as  "a 
source  of  considerable  frustration  in  attempting  to  execute 
their  responsibilities  in  the  face  of  inadequate  authority, 
misunderstanding,  skepticism  and  even  hostile  attitudes." 
[Ref.  18 : p .  17]  Frustration  results  from  having  to 
coordinate  various  activities  with  personnel  on  several 
levels  within  the  organization  and  needing  to  give  effective 
direction  to  personnel  that  do  not  report  to  them  in  the 
formal  chain  of  command  [Ref.  18:p.  34].  Within  NMPC-47, 
project  management  operates  in  an  organization  structured  as 
a  matrix.  Resources  and  taskings  go  across  traditional 
organizational  lines  and  the  personnel  tasked  are  working 
for  two  bosses,  LT  Hopkins,  the  project  officer  and  their 
functional  manager. 

c.  Matrix  Management 

Using  a  matrix  structure  is  the  preferred 
arrangement  when  the  following  three  basic  conditions  exist 
simultaneously  within  an  organization:  (1)  outside  pressure 
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for  dual  focus;  (2)  pressures  for  high  information 
processing  capacity;  and  (3)  pressures  for  shared  resources. 
A  dual  focus  refers  to  a  situation  where  two  issues  are 
critical  to  the  organization's  survival.  In  the  case  of 
NMPC-47,  the  dual  focus  is  for  development  of  OAIS  and  the 
continued  manual  maintenance  of  functions  required  by 
assignment  and  placement  personnel.  Neither  function  can  be 
allowed  to  overrule  the  other  as  they  are  both  critical  to 
the  continued  fulfillment  of  the  organization's  mission.  A 
balance  of  power  must  be  maintained  between  the  two  areas 
and  each  issue  must  be  addressed  during  decision  making 
especially  decisions  dealing  with  costs,  schedules,  and 
personnel.  Having  pressures  for  a  high  information 
processing  capacity  are  the  result  of  relatively  unstable 
and  unpredictable  demands  on  the  organization.  This 
unstable  condition  dictates  the  need  for  additional 
information  processing.  The  unstable  condition  in 
conjunction  with  unknown  future  events,  such  as 
technological  advances,  environmental  rulings  and  government 
regulations,  requires  consultation  with  many  members  in  the 
organization.  These  additional  personnel  involved  in 
decisions  increase  the  complexity  of  the  decision  making  and 
increase  the  requirement  for  additional  information 
processing.  NMPC-47  is  in  an  unstable  condition.  OAIS  has 
been  developed  by  contractors  and  implemented  for  330  users. 
The  Information  Systems  Support  branch,  N471,  has  just 
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received  its  first  computer  and  OAIS  has  transferred  from 
the  leased  machine  to  the  hardware  in-house.  The  first 
major  change  to  OAIS,  software  conversion  and  enhancement  to 
the  orderwriting  module,  is  underway.  NMPC-47  is  dealing 
with  changes  in  technology  as  well  as  supporting  330  OAIS 
users  and  implementing  a  major  change.  The  expertise  of 
many  personnel  located  throughout  the  department  is  needed 
in  the  decision  making  process  to  ensure  the  continued 
smooth  operation  of  OAIS  and  the  development  of  the  OAIS 
enhancement.  The  third  condition  for  a  matrix  structure  is 
pressures  for  shared  resources.  By  sharing  resources, 
economies  of  scale  are  achieved,  scarce  resources  are 
available  and  costs  can  be  decreased.  For  NMPC-47,  the 
resources  consist  of  human  and  computer  resources.  Of 
particular  concern  are  the  technically  proficient  personnel 
in  the  Information  Systems  Support  branch,  whose  expertise 
is  needed  for  assistance  with  the  OAIS  enhancement.  The 
expertise  of  the  Order  Support  branch  personnel  concerning 
the  requirements  of  officer  orders  is  also  needed  during  the 
design  of  the  orderwriting  module.  [Ref.  19:pp.  13-18] 

There  are  advantages  and  disadvantages  to  a 
matrix  structure.  Besides  assisting  with  the  above  three 
conditions,  a  matrix  structure  can  also  create 
opportunities.  There  is  the  opportunity  for  growth  in 
individual  knowledge  and  skills  that  is  not  possible  in  the 
traditional  organization  structure  [Ref.  19:p.  103].  With 
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the  increase  in  complexity  and  personnel  involved  in 
decision  making  comes  increased  amounts  and  patterns  of 
contact  between  individuals  [Ref.  19:p.  104].  This 
increased  contact  increases  the  requirement  for 
communication.  Communicating  with  the  necessary  personnel 
takes  additional  time  and  enhanced  communication  skills. 
Conflicts  between  individuals  are  certain  to  arise. 

Conflicts  can  be  looked  at  from  a  positive  viewpoint.  If 
all  the  personnel  involved  in  a  conflict  air  their  opinions 
and  the  assumption  is  that  everyone  is  working  for  the 
common  good  of  the  project,  then  it  may  be  possible  to 
arrive  at  the  best  solution  to  a  problem  [Ref.  19:p.  104]. 

A  decision  can  not  just  be  made  one  day  to 
transition  to  a  matrix  structure  and  the  next  day  do  it  and 
achieve  success.  The  process  of  the  transition  doesn't  just 
involve  changes  to  the  organization  chart.  Changes  are  also 
required  in  the  systems,  culture  and  behavioral  patterns  of 
the  personnel  involved.  The  success  of  a  matrix  is 
dependent  on  the  organization  helping  the  personnel  to 
understand  and  function  in  new  ways  [Ref.  19:p.  103].  For 
the  most  part,  people  are  brought  up  in  the  "one  person-one 
boss"  tradition.  Switching  over  to  being  responsible  to  two 
bosses  often  involves  stress  and  uncertainty  due  to  the 
possibilities  of  conflicting  interests  and  loyalty  to 
functional  responsibilities  [Ref.  19:p.  18]. 
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■  n 

In  this  case  study,  NMPC-47  had  just  made  the 
switch  to  the  matrix  structure.  The  time  was  not  taken  to 
educate  personnel,  management  or  to  prepare  the  organization 
for  the  change.  Development  concerns  had  top  priority.  A 
matrix  organization  for  accomplishment  of  OAIS  project 
management  was  the  means  to  the  end.  If  the  time  had  been 
taken  to  educate  those  involved,  establish  procedures  and 
standards,  many  of  the  problems,  primarily  those  concerning 
conflicts,  could  have  been  diminished.  Conflicts  in 
computer  system  project  itu  agement  can  be  generated  from  the 
following:  project  priorities,  administrative  procedures, 

technical  opinions,  perf' -mance  trade-off  decisions, 
utilization  of  manpower  resources,  cost,  schedules, 
personality  and  intensity  of  work  required  according  to  the 
phase  of  the  life  cycle  that  the  project  is  in  [Ref.  18 :p. 

« 

46]  . 

Conflict  can  be  minimized  by  the  managerial 
behavior  of  the  project  officer.  Managerial  behavior 
concerns  approaching  functional  managers  with  flexibility, 
understanding  of  both  sides  of  an  issue  and  by  avoiding 
absolute  statements  of  requirements  [Ref.  19:p.  51]. 

Project  officers  must  rely  heavily  upon  their  interpersonal, 
group  management,  and  communication  skills  to  influence 
people  to  do  what  is  essential  for  project  success.  When 
project  officers  are  dealing  with  their  peers  within  an 
organization,  Stanley  Davis  and  Paul  Lawrence  suggest  that 


108 


they  determine  how  the  other  person  operates  and  with  this 
knowledge  establish  an  individual  relationship  with  each  of 
the  different  personnel  on  the  project  [Ref.  19:p.  88]. 

In  particular,  for  development  of  a  computer 
application,  the  three  areas  most  likely  to  cause  conflicts 
are  priorities,  manpower  resources  and  schedules  [Ref.  18:p. 
53],  Each  of  the  functional  managers  has  his/her  own 
schedules,  priorities  and  workload  which  must  be  fulfilled. 
It  is  a  given  that  the  original  plans  and  schedule  will 
change  as  the  project  is  developed.  Each  computer  project 
will  be  different,  will  be  developed  by  a  different  team  of 
personnel  and,  in  particular,  the  unexpected  can  occur  when 
dealing  with  new  technology.  By  keeping  personnel  involved 
with  the  project  as  up  to  date  as  possible,  the  project 
officer  can  lessen  the  surprises  and  crisis  situations  which 
lead  to  conflicts. 

In  addition  to  managerial  behavior,  the 
establishment  of  interpersonal  influence  bases  are  helpful 
to  a  project  officer  in  performing  his/her  job.  Three 
influence  bases  suggested  by  Russell  D.  Archibald  are:  (1) 
reward  and  punishment  power;  (2)  expert  power;  and  (3) 
referent  power.  Reward  and  punishment  power  involves  having 
the  power  to  either  block  or  facilitate  the  attainment  of 
personnel  or  career  goals  of  the  people  working  on  the 
project.  Expert  power  refers  to  the  expertise  of  the 
project  officer  concerning  the  specific  topic  or  project. 
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Expert  power  is  conferred  on  the  project  officer  if  the 

personnel  feel  he/she  has  greater  expertise  than  they  do  in 

the  subject  matter  or  that  he/she  is  more  qualified  to  make 

decisions  than  they.  Referent  power  is  when  the  personnel 

are  personally  attracted  to  the  project  officer  and  value 

that  relationship  and  the  project  officer's  opinion  of  them. 

Personal  friendships  and  alliances  can  become  an  important 
source  of  influence  for  a  project  manager.  If  a  project 
manager  is  personally  disliked,  he  many  have  negative 
referent  power,  which  will  make  the  task  of  influencing 
the  project  contributors  even  more  difficult.  [Ref. 

18 : pp.  45,  44-45] 

d.  LT  Hopkins'  Management 

LT  Hopkins  did  not  integrate  the  efforts  of  the 
project  team  members  in  the  project.  Functional  managers 
and  team  personnel  continued  on  with  their  functional 
responsibilities,  but  there  was  no  team  effort  working  on 
making  the  OAIS  project  a  success.  For  example,  personnel 
in  the  Information  Systems  Support  branch,  N471,  where  the 
Systems  Administration  and  Configuration  Management 
functions  are  located,  were  not  invited  to  meetings  nor 
consulted  or  apprised  of  OAIS  plans.  The  Training  Officer 
was  also  not  involved  in  the  development  of  OAIS.  Changes 
being  made  to  OAIS  were  of  particular  importance  to  the 
Training  Officer,  but  this  information  was  not  available 
until  a  month  before  implementation  of  the  new  system.  The 
most  significant  lack  of  coordination  occurred  with  the 
combination  Navy  and  contractor  programmer  team.  The  two 
groups  were  working  on  separate  portions  of  OAIS, 
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orderwriting  and  software  conversion  respectively,  but 
coordination  of  their  progress,  scheduling  of  computer  time, 
and  planning  for  the  eventual  combination  of  their  two 
programs  was  not  done. 

LT  Hopkins  was  a  new  project  officer  and  many 
knowledgeable  personnel  had  left  the  OAIS  project,  but  that 
does  not  excuse  her  disregard  for  acceptable  managerial 
behavior.  Cooperation  with  LT  Hopkins  may  have  been  more 
forthcoming  if  she  had  approached  the  functional  managers  in 
N471  first  as  a  courtesy  measure  in  regards  to  tasking  their 
manpower  or  need  for  a  schedule  change.  LT  Hopkins  did  not 
have  good  interpersonal  relationships  with  the  functional 
managers.  Her  aggressive  manner  and  "I  want  it  done  now" 
attitude  contributed  to  the  problem.  Thus,  she  reduced  her 
effectiveness  and  was  not  able  to  build  a  power  base  from 
which  to  launch  the  project.  Assistance  was  available  if 
she  had  only  asked  for  it  from  her  peers  responsible  for 
portions  of  functional  management.  In  particular,  CDR  Hazel 
was  an  acknowledged  functional  expert  on  OAIS.  The  ability 
to  build  an  expert  power  base  by  becoming  an  functional 
expert  on  the  OAIS  system  was  available  to  LT  Hopkins.  She 
did  not  make  an  effort  to  acquire  the  knowledge.  If  she 
had,  in  addition  to  building  her  expert  power  base,  she 
would  have  been  able  to  ask  some  intelligent  questions 
throughout  the  OAIS  development  process.  From  this  she  may 
have  been  able  to  identify  some  of  the  problems  prior  to 
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implementation.  The  third  power  base,  that  of  reward  and 
punishment  power,  was  not  available  to  LT  Hopkins  due  to  the 
inadequate  implementation  of  the  matrix  structure  in  the 
organization.  Personnel  affected  by  the  two  boss  situation 
did  not  view  tasking  by  LT  Hopkins  on  the  same  level  as 
tasking  by  their  functional  boss. 

There  are  several  factors  which  may  have 
contributed  to  LT  Hopkin's  poor  performance  as  a  project 
officer.  One  factor  was  the  mindset  of  the  project  officers 
in  regard  to  the  contractor.  The  mindset  was,  "We  are 
paying  big  bucks  for  a  quality  product."  Therefore,  LT 
Hopkins  did  not  have  any  indication  that  more  involvement 
with  the  contractor  was  necessary  than  that  of  her 
predecessor.  In  the  history  of  OAIS,  the  contractors  had 
been  taken  at  their  word  concerning  all  aspects  of  systems 
development  and  production.  The  contractors  had  not  been 
wrong  yet,  which  was  one  of  the  reasons  that  the  OAIS 
reputation  was  good  with  both  users  and  management. 

However,  when  LT  Hopkins  reported  aboard,  NMPC-47's  project 
officer  and  the  project  manager  for  the  contractor  both 
left.  This  left  just  a  handful  of  personnel  familiar  with 
OAIS  functions  and  history  involved  with  the  project. 
Additionally,  with  OAIS  documentation  of  poor  quality,  there 
were  no  references  to  turn  to  for  assistance  with  problem 
solving.  Lastly,  previous  development  efforts  and  project 
managers  did  not  have  to  contend  with  relationships  with 
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training,  systems  administration  or  configuration 
management.  These  functions  had  not  existed  then.  This  may 
explain  some  of  the  lack  of  inclusion  of  Information  Systems 
Support  branch  personnel  in  OAIS  planning, 
e.  Pre-Implementation  Problems 

Pre-implementation  activities  typically  involve 
the  testing  of  the  program,  and  training  for  users  and 
operators.  Testing  of  the  program  can  be  broken  down  into 
four  types  of  testing.  There  is  individual  module  testing 
or  unit  testing,  to  ensure  that  the  internal  workings  of  the 
module,  the  data  structures,  error  handling  routines,  and 
the  input  and  output  parameters  work  properly.  Next  is 
integration  testing.  This  is  where  all  the  individual 
modules  are  combined  and  tested  for  proper  interfaces  and 
data  passing  and  their  ability  to  work  together.  The  third 
test  is  a  system  test.  This  test  includes  all  the  factors 
that  make  up  a  system,  the  hardware,  software,  peripheral 
equipment,  people  and  procedures.  This  test  is  to  ensure 
that  all  factors  work  together  and  perform  their  allocated 
function.  The  fourth  test  is  validation  of  the  system. 
Validation  is  a  check  to  ensure  that  the  customers'  original 
requirements  of  what  the  system  is  supposed  to  do  are 
fulfilled.  The  second  major  pre-implementation  activity  is 
user  and  operator  training.  User  training  consists  of  two 
parts — provision  of  formal  user  documentation  on  how  the 
system  works  and  "hands-on"  training.  "Hands-on"  training 
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is  the  actual  usage  of  the  computer  application.  Users 
become  familiar  with  both  the  computer  itself  and  the 
application  implemented  on  the  computer.  Users  that  are 
trained  before  implementation  are  much  more  likely  to  accept 
the  new  system  and  be  less  frustrated  when  things  go  wrong. 
Operator  training  is  the  training  of  the  production  control 
and  scheduling  personnel  concerning  new  procedures  for 
running  batch  jobs.  Having  operators  familiar  with  new  job 
control  language,  sequencing  of  jobs  and  indicators  of 
smooth  running  operations  is  essential  for  successful 
implementation  of  the  new  application. 

During  preparation  for  the  implementation  of 
OAIS ,  some  training  and  some  testing  were  completed.  User 
training  was  conducted  in  a  conference  room  with  the  new 
user  documentation.  "Hands-on”  training  was  not  a  viable 
option  due  to  the  lack  of  a  training  facility  and  test 
computer  application.  Individual  testing  was  done  on  the 
modules.  This  testing  was  done  in  the  evening  due  to  the 
lack  of  a  testing  facility  on  the  computer.  Integration, 
system  and  validation  testing  did  not  take  place.  Before 
OAIS  came  up,  there  had  never  been  a  complete  run-through  of 
the  whole  application  or  system  nor  validation  of  what  the 
application  was  supposed  to  do  for  the  users, 
f.  Development  Team 

The  programming  team  for  development  of  the  OAIS 
conversion  and  orderwriting  module  consisted  of  two  groups. 
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One  group  was  the  contractors  and  their  main  job  was 
conversion  of  the  APSCOBOL  code  from  version  JK  to  version 
1.7.  The  other  group,  made  up  of  Navy  Data  Processing 
Technicians  (DP's),  was  responsible  for  coding  the  newly 
designed  orderwriting  module.  For  the  most  part,  the  DP's 
were  experienced  programmers.  There  was  a  reason  behind 
this  integrated  programming  team.  The  reason  was  that 
maintenance  of  OAIS  would  be  the  Navy's  responsibility  once 
this  version  of  OAIS  was  implemented.  By  having  the  DP's 
participate  in  the  prograr.  ing,  they  would  gain  some 
valuable  experience  with  the  language.  Unfortunately,  there 
was  no  coordination  amonc  the  programming  teams.  For  the 
most  part  each  worked  in  isolation.  The  code  the 
contractor's  were  converting  would  be  interfacing  with  the 
new  orderwriting  module  in  several  situations.  The  two 
would  be  passing  data  for  order  generation  over  an  interface 
as  well  as  creating  batch  reports.  The  lack  of  testing  is 
unexcusable . 

D.  CASE  STUDY  THREE  TEACHING  NOTE 
1 .  Questions 

What  accounts  for  the  failure  of  OAIS? 

What  does  CDR  Griffin  mean  when  he  says  "project  office 
people  always  seem  to  forget  the  production  portion  of 
this  business"? 

If  you  were  LT  Hopkins,  what  would  you  do  when  the  new 
version  is  taken  out  of  production? 
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2 .  Case  Summary 

This  case  study  covers  the  timeframe  immediately 
following  the  implementation  of  the  new  version  of  OAIS. 

The  attitude  and  thoughts  of  NMPC-47  management  are 
described.  Reactions  to  the  failure,  and  procedures  to 
guard  against  problems  happening  in  the  future  are 
addressed.  A  major  manpower  cut  by  OP-01  causes  a  change  to 
the  maintenance  plans  and  contract  management  for  OAIS. 

3 •  Major  Issues/Problems 

Project  Management  in  a  poorly  implemented  matrix 

structured  organization. 

Lack  of  testing. 

Lack  of  concern  for  production  issues. 

LT  Hopkins's  actions. 

4 .  Case  Analysis 

a.  Causes  of  OAIS  failure 

(1)  Project  Management.  Russell  Archibald 
states  that  the  following  six  causes  are  the  reasons  for  the 
poor  performance  on  projects  [Ref.  18:p.  10]: 

Poor  understanding  of  the  project  manager  job. 

Wrong  type  of  person  assigned  as  project  manager. 

Excessive  conflict  between  project  and  functional 

managers . 

No  integrated  planning  and  control. 

-  Rapidly  changing  and  conflicting  project  priorities. 

Improperly  organized  and  staffed  project  offices. 
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The  first  four  of  these  causes  apply  to  the  OAIS  failure. 
These  four  problems  can  be  attributed  to  the  poor 
introduction  of  the  matrix  structure  for  OAIS  project 
management  in  NMPC-47.  Without  education  of  personnel 
involved  in  the  change  to  a  matrix  structure  and  the 
subsequent  change  to  procedures,  and  behaviors,  there  will 
be  a  poor  understanding  of  the  project  manager  job. 

Personnel  tasked  by  LT  Hopkins  did  not  feel  that  her  tasking 
was  of  equal  importance  as  tasking  from  their  functional 
managers.  Being  a  project  manager  requires  competence  in 
working  with  people,  force  of  personality  and  skills  in 
group  management  [Ref.  19:p.  87].  By  choosing  a  project 
manager  who  lacks  these  skills  and  relationships,  the  job  is 
put  in  jeopardy  of  failing.  Influencing  functional  managers 
and  negotiating  for  the  success  of  the  project  are  a  large 
part  of  the  job.  LT  Hopkins  lacked  the  interpersonal  skills 
necessary  to  both  motivate  people  and  to  facilitate  project 
tasking.  In  particular  for  NMPC-47,  by  LT  Hopkins  lacking 
these  skills,  the  problems  inherent  from  the  incomplete 
introduction  of  the  matrix  structure  in  the  organization 
were  magnified.  These  problems  were  evident  in  the 
excessive  conflict  between  the  functional  managers  and  the 
project  officer.  LT  Hopkins  resorted  to  an  aggressive  style 
and  by  issuing  absolute  statements.  The  mandating  of 
absolutes  is  a  condition  that  Stanley  Davis  and  Paul 
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Lawrence  state  is  detrimental  to  working  within  the  matrix 
structure . 

The  lack  of  integrated  planning  and  control 
of  the  project  development  team  is  the  underlying  reason  for 
the  failure.  This  lack  of  integrated  planning  and  control 
is  particularly  evident  in  the  lack  of  coordination  between 
the  two  different  parts  of  the  programming  team.  This  lack 
of  control  led  to  a  lack  of  integration  and  systems  testing 
which  ultimately  caused  OAIS  to  fail.  The  lack  of 
integrative  planning  and  control  was  also  evidenced  by  not 
including  Information  Systems  Support  branch  personnel  in 
OAIS  development  planning.  With  the  inclusion  of  all 
personnel  whose  expertise  is  needed  to  assist  with  the 
development  of  OAIS,  a  lot  of  problems  could  have  been 
identified  earlier  in  the  project  development. 

(2)  Lack  of  Testing.  The  primary  cause,  on  the 
surface,  of  the  OAIS  failure,  was  the  degraded  systems 
performance  caused  by  the  converted  code.  The  system  slowed 
response  time  for  user  requests.  This  situation  was  allowed 
to  continue  for  two  days  until  user  complaints  were  so 
numerous  that  top  management  could  not  ignore  them.  The 
users  had  become  dependent  on  OAIS  for  production  of  their 
everyday  work.  They  were  unable  to  do  their  jobs  for  two 
days.  When  the  new  version  of  OAIS  was  taken  down,  there 
was  another  day  of  computer  unavailability.  A  total  of 
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three  days  were  lost,  an  unnecessary  consequence  due  to  a 
lack  of  testing  prior  to  implementation. 


(3)  Organization  Inexperience.  NMPC-47  is 
relatively  new  in  the  automated  data  processing  business. 

In  addition  to  project  officer  problems  and  poor  matrix 
introduction  to  the  organization,  NMPC-47  is  making  mistakes 
because  of  inexperience.  The  contractors,  who  had 
implemented  the  original  version  of  OAIS  did  not  see  the 
need  for  more  testing  of  the  application.  NMPC-47  had  not 
had  to  question  the  contractor  previously  and  did  not  know 
any  differently. 

b.  Lack  of  Concern  for  Production  Issues 

CDR  Griffin's  comment  concerning  how  the  project 
office  people  always  seem  to  forget  the  production  side  of 
the  business  can  be  construed  to  indicate  a  lack  of  integra¬ 
tion.  CDR  Griffin's  comment  acknowledges  the  management 
emphasis  in  NMPC-47,  both  past  and  present,  which  is  on 
development.  With  over  300  users  dependent  on  OAIS, 
maintaining  production  OAIS  should  have  been  of  equal 
importance  to  enhancement  of  the  application.  To  ensure 
proper  addressing  of  production  issues,  N471  personnel 
should  have  been  included  in  OAIS  plans  and  decision  making. 

c.  LT  Hopkins  Management  Changes 

LT  Hopkins  advocated  two  changes  to  the 
management  of  the  OAIS  application.  She  wanted  OAIS 
modularized  into  smaller  portions  and  test  plans  to  be  drawn 
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up  for  each  screen,  module,  program  and  interface  of  OAIS. 
These  two  changes  were  good  decisions. 

Having  OAIS  broken  down  into  smaller  modules 
will  facilitate  testing,  detection  and  correction  of  errors. 
Error  detection  and  correction  is  made  easier  as  the  code 
that  needs  to  be  debugged  is  localized  instead  of  being 
spread  through  out  the  program.  Also  by  having  a  smaller 
portion  of  code  to  test,  programs  can  be  debugged  more 
thoroughly  [Ref.  20:p.  131].  Modularization  also  provides 
for  the  evolvability  of  the  software  [Ref.  ll:p.  697].  If  a 
change  needs  to  be  made,  the  module  can  be  coded  and 
inserted  in  the  program  with  a  minimum  of  effort  and  changes 
to  other  interfacing  modules. 

By  mandating  test  plans  for  each  screen,  module, 
program  and  interface,  there  will  be  assurance  that 
integrative  and  validation  testing  have  been  performed. 
Additionally,  having  the  users  involved  in  conducting  the 
test  plans  will  increase  their  confidence  in  the  new  system 
and  assist  with  their  training  on  changes  contained  in  the 
new  version. 

One  recommended  change,  that  of  having  one  group 
in  control  and  responsible  for  the  programming  phase,  was 
taken  care  of  by  the  manpower  cuts.  This  manpower  cut  laid 
the  framework  of  the  future  for  NMPC-47.  NMPC-47  will  now 
be  dependent  on  contractors  for  development  and  maintenance 
of  their  computer  applications.  This  change  affected  the 
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management  of  the  entire  life  cycle,  in  particular  adding 
additional  costs  for  contractor  resources  to  ensure  the 
continued  operation  of  OAIS.  An  additional  recommendation 
is  that  if  LT  Hopkins  continues  her  mode  of  operation  of 
being  the  sole  interface  with  the  contractor,  she  should 
become  more  of  a  functional  expert  on  OAIS  and  user 
requirements . 

E.  CASE  STUDY  FOUR  TEACHING  NOTE 
1 •  Questions 

What  are  indicators  c  maturity  in  NMPC-47? 

What  is  the  structure  of  the  IS  organization? 

Will  the  OAIS  imple:  •  itation  be  a  success? 

2 .  Case  Summary 

This  case  study  describes  the  activities  of  NMPC-47 
during  the  time  period  of  May  1986  through  May  1987.  The 
primary  activity  taking  place  is  the  redevelopment  of  a  new 
version  of  OAIS.  Changes  within  tt '  organization  include 
transition  from  a  development-oriented  department  to  a 
production-oriented  department  wit  an  emphasis  on  customer 
support.  OAIS  usage  has  increased.  There  are  more 
terminals  available  than  there  are  ports  on  the  bus 
interface  units  connected  to  the  local  area  network.  OAIS 
users  have  become  more  comfortable  with  OAIS  and  in  ue 
process  discovered  unprotected  data  fields  and  ways  to  use 
OAIS  information  and  screens  that  were  not  intended. 

Lessons  learned  from  the  implementation  in  May  1986  of  OAIS 
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are  applied  to  this  implementation  effort.  A  systems  stress 
test  is  planned  and  executed.  Test  Plans  are  used  for 
integration  and  validation  tests. 

3 .  Major  Issues/Problems 

Maturity  of  OAIS. 

Centralization  of  computing  resources. 

User  sophistication. 

IS  organization  transition. 

Incorporation  of  lessons  learned  in  May  86 

implementation . 

Pre-implementation  activities. 

4 .  Case  Analysis 

a.  Nolan's  Stages  of  Growth 

NMPC-47  displays  characteristics  of  both  the 
third  and  fourth  stages  of  Nolan's  Stages  of  Growth.  The 
third  stage  is  called  Formalizing  Control.  Characteristics 
of  this  phase  that  NMPC-47  is  exhibiting  are  growing  pains 
towards  maturity,  some  centralization  of  resources  and 
equipment  and  an  emphasis  on  processes  instead  of  products. 
The  growing  pains  and  emphasis  on  processes  is  evidenced  by 
the  transition  from  a  development-oriented  department  to  a 
production-oriented  department.  A  process  of  customer 
support  has  developed  and  it  resulted  from  the  consolidation 
of  several  separate  products  such  as  hardware  repair,  error 
research  and  report  generation.  The  fourth  stage  is  called 
Realignment  and  Integration  of  Processes.  Characteristics 
of  this  stage  that  apply  to  NMPC-47  include  user 
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sophistication  and  stability  of  operations.  [Ref.  ll:pp. 
673-674] 

(1)  OATS  Maturity.  The  recognition  of  the 
usefulness  of  OAIS  information  has  grown.  Requests  for 
access  to  OAIS  are  received  from  other  commands.  OAIS  is 
not  viewed  as  just  facilitating  the  lives  of  assignment  and 
placement  officers  within  NMPC,  but  as  being  important  to 
personnel  planning  activities  external  to  NMPC.  Recognition 
of  the  importance  of  OAIS  information  has  personnel  within 
NMPC  competing  for  access  to  the  application.  There  are 
more  terminals  than  there  are  bus  interface  units  on  the 
local  area  network.  Primary  and  secondary  users  are 
designated  and  specific  ports  are  assigned  to  primary  users. 
Competition  for  ports  has  caused  port  pirating. 

Considerable  administrative  time  is  spent  solving  the  port 
pirate  problems  of  users  phoning  the  OAIS  Help  Desk. 

Assignment  and  placement  officers  had 
relied  on  OAIS  for  quite  some  time.  Now  user  top  management 
is  also  depending  on  OAIS  generated  information  to  do  their 
job.  In  recognition  of  the  increasing  reliance  on  OAIS, 

OAIS  Help  Desk  personnel  were  required  to  inform  NMPC-47  top 
management,  and  the  Admiral  in  NMPC-4 ,  whenever  there  was  a 
major  problem  with  OAIS.  Also,  CDR  Griffin  established  the 
NMPDS  Crisis  Management  Team.  The  make-up  of  the  team, 
technic- 1  personnel  from  N471,  was  a  statement  supporting 
the  production-orientation  of  the  branch. 
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(2)  Centralization  of  Resources.  Computer 


operations  are  fairly  stable.  There  are  time  and  resources 
available  to  address  production-oriented  issues  such  as 
security,  and  customer  support.  A  new  security  system  is 
implemented,  a  test  OAIS  application  is  implemented  and  a 
dial-up  capability  for  OAIS  users  out  in  the  field  is 
implemented. 

The  implementation  of  the  new  security 
system,  in  essence  a  shell  surrounding  the  entire  NMPDS 
application,  is  also  evidence  of  planning  for  the  future 
integration  of  the  four  applications  within  NMPDS.  The  need 
for  a  test  application  was  evident  during  the  previous 
implementation  attempt.  It  is  available  now  due  to  the 
availability  of  additional  computer  resources  and  a  planning 
for  the  future  of  OAIS  within  the  command.  The  dial-up 
capability  is  an  enhancement  to  the  customer  support 
process.  The  customer  support  process  is  also  enhanced  with 
the  consolidation  of  all  user  support  functions  into  the 
OAIS  Help  Desk.  Previously  the  separate  products  of  error 
research,  hardware  repair  and  OAIS  status  information  were 
handled  by  separate  divisions  within  N471.  With  the 
consolidation  of  all  user  support  resources  into  a  central 
agency,  the  customer  is  served  more  efficiently  and 
effectively. 

(3)  User  Sophistication.  OAIS  users  are  very 
comfortable  with  the  system.  With  this  comfort  comes 
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exploration  (hacking)  of  the  program.  Unprotected  data 
fields  are  discovered,  screens  are  used  for  purposes  for 
which  they  were  not  intended  and  information  contained 
within  the  system  is  used  for  personal  benefit.  Examples  of 
these  unintentional  uses  are  the  Aviator's  use  of  a  screen 
for  their  internal  phone  list  that  was  originally  designed 
for  the  Submarine  Department,  and  the  review  of  personal 
information  on  doctors  and  lawyers  before  using  their 
services . 

With  user  sophistication  and  additional 
computer  resources,  application  development  has  been 
enhanced.  This  has  resulted  in  increased  usage  of  the  On¬ 
line  Adhoc  Information  System  (ODIS)  and  electronic  mail 
applications.  ODIS  is  a  database  system  which  users  may 
access  with  a  little  training  on  boolean  algebra.  ODIS 
provides  reports  and  information  in  a  customized  format,  and 
a  query  capability.  The  current  use  of  electronic  mail  is 
sporadic  across  the  Distribution  Division,  but  several 
departments  have  started  relying  on  it  for  internal 
messages . 

b.  Information  Systems  Department  Structure 
There  are  three  primary  functions  that  are 
typically  performed  by  a  Information  Systems  department. 
These  are  development,  maintenance  and  production  control. 
Development  is  concerned  with  the  analysis,  design, 
programming,  testing,  documentation,  project  management  and 
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implementation  cf  new  applications.  Maintenance  is 
concerned  with  the  continued  operation  of  current 
applications.  Production  control  deals  with  the  processing 
of  daily  operations,  such  as  updates,  report  generation  and 
output,  which  are  necessary  for  the  continued  viability  of 
the  computer  applications.  Two  support  functions  are  also 
necessary  within  an  Information  Systems  department: 
administrative  and  technical  support.  The  administrative 
function  deals  with  planning,  budgeting  and  personnel.  The 
technical  support  function  addresses  systems  programming, 
communications  control,  system  monitoring,  technical 
assistance,  user  assistance  and  data  processing  standards. 
[Ref.  21 : p.  90] 

The  Information  Systems  department,  NMPC-47, 
transitions  from  a  development-oriented  to  a  production- 
oriented  organization.  As  an  information  systems  department 
matures,  its  operations  become  more  important.  This 
importance  is  due  to  the  resources,  in  the  form  of 
personnel,  equipment  and  software,  which  are  needed  for  the 
continued  support  of  computer  systems  in  the  organization. 
Once  an  application  has  been  implemented  and  integrated  into 
the  operational  routine  of  the  organization,  it  cannot  be 
discarded  nor  changed  drastically  due  to  user  dependence. 
[Ref.  20 : p .  46] 

Prior  to  this  transition,  N470,  the  Information 
Systems  Development  branch,  was  responsible  for  management 
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of  all  three  primary  functions  and  parts  of  both  support 
functions.  This  was  accomplished  through  a  matrix 
structure.  Development  was  handled  through  contractors  with 
liaison  between  the  contractors  and  the  Navy  in  the  form  of 
a  project  officer  in  N470.  Maintenance  was  accomplished  by 
the  Application  Programming  Shop  in  N470,  while  the  need  for 
the  maintenance  was  determined  in  N471  and  N472.  Project 
officers  in  N470  determined  production  control  priorities 
while  the  personnel  doing  the  production  control  work  were 
located  in  N471.  Refer  to  Figure  3  in  Case  Study  Two. 

This  matrix  ma.  agement  caused  conflicts  over 
work  priorities,  chain  of  command,  and  usage  of  personnel 
resources.  Whenever  there  was  a  problem  with  production 
OAIS ,  LT  Perkins  at  the  OAIS  Help  Desk  had  to  consult  with 
LT  Hopkins.  In  addition  to  wasting  time,  LT  Hopkins  was  not 
fully  aware  of  the  impact  of  certain  production  problems  on 
the  users  of  OAIS.  CDR  Griffin  and  cDR  rcice,  oranch  heads 
for  N471  and  N470  respectively,  also  had  conflicts  over 
allocation  of  resources  and  develop  -ent  versus  production 
priorities.  With  the  priorities  of  rhe  project  management 
personnel  taking  precedence  over  those  of  production  and 
technical  support,  both  system  readiness  and  the  morale  of 
personnel  was  low. 

Once  the  transition  of  responsibility  for 
production  decisions  was  made  from  N470  to  N471,  the 
responsibility  for  the  three  primary  functions  and  two 
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secondary  functions  was  more  evenly  divided  between  the  two 
departments.  Refer  to  Figure  4  in  Case  Study  Four.  The 
Information  Systems  Development  branch,  N470,  continued  to 
have  responsibility  for  application  development.  Their 
responsibility  for  maintenance  was  a  temporary  requirement 
until  the  new  version  of  OAIS  was  implemented.  The 
Information  Systems  Development  branch,  N470,  had 
responsibility  for  only  one  support  function,  the 
administrative  function.  Systems  Administration  in  N471 
took  over  full  responsibility  for  the  production  control 
function  and  some  of  the  technical  support  functions  such  as 
systems  programming,  systems  performance  monitoring  and 
configuration.  Other  technical  support  activities  were 
handled  by  Configuration  Management  and  the  OAIS  Help  Desk. 
Configuration  Management  was  responsible  for  technical 
assistance  and  data  processing  standards.  The  OAIS  Help 
Desk,  Training  and  personnel  in  N472  were  responsible  for 
user  assistance. 

Customer  service  is  one  of  six  critical  areas 
needing  management  control  to  ensure  continued  efficiency 
and  effectiveness  of  the  computer  systems  [Ref.  20:p.  62]. 
Afterall,  the  computer  system  is  for  the  users.  The  move  of 
the  training  function  from  N470  to  N471  and  the 
consolidation  of  responsibility  for  all  customer  contact 
into  the  OAIS  Help  Desk  facilitated  the  development  of  a 
total  customer  service  concept.  The  main  idea  was  to 
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provide  one-stop  shopping  for  the  users.  Prior  to  this 
consolidation,  users  had  to  call  Error  Research  if  they  had 
a  problem  with  officer  orders,  or  call  Systems 
Administration  if  there  was  a  problem  with  the  computer 
hardware  or  a  printer,  or  call  Production  Control  if  there 
was  problem  with  receipt  of  a  report.  CDR  Griffin 
recognized  the  need  of  having  one  organization  responsible 
for  interface  with  the  users.  This  consolidation  ensured 
quicker  and  better  service  to  the  user.  The  OAIS  Help  Desk 
also  assisted  in  achieving  better  communications  with  the 
users.  Personnel  at  the  OAIS  Help  Desk  called  each 
department's  user  representative  to  pass  along  important 
information  concerning  an  OAIS  problem  or  computer  downtime. 

A  logbook  to  log  all  phone  calls  into  the  OAIS 
Help  Desk  was  established.  If  a  problem  was  called  in 
concerning  a  hardware  problem  or  report  problem,  a  trouble 
report  was  sent  to  the  appropriate  part  of  N471  for 
correction.  The  time  was  logged  and  if  feedback  was  not 
received  at  the  OAIS  Help  Desk  within  a  reasonable  amount  of 
time  from  the  appropriate  section  of  N471  responsible  for 
the  correction,  follow-up  action  was  taken.  This  audit 
trail  ensured  that  a  user's  problem  would  not  be  overlooked. 
Additionally,  the  logbook  provided  a  composite  of  user 
problems.  From  this  consolidation  it  was  possible  to  spot 
trends-  concerning  problem  prone  hardware  or  frequency  of 
errors . 
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The  change  of  the  organization  focus  to 
production  issues  and  customer  support  brought  about  changes 
to  the  jobs  that  the  Data  Processing  Technicians  (DP's)  had 
been  performing  in  NMPC-47.  Most  DP's  want  to  program. 

Most  programmers  have  a  job  orientation  towards  systems 
development,  even  though  the  majority  of  the  work  is 
production  and  maintenance  oriented  [Ref.  22:p.  9].  The 
DP's  experienced  the  maturity  of  the  organization  by  seeing 
it  progress  from  an  organization  where  the  focus  was 
computers  and  programming  to  an  organization  where  the  user 
and  user  desires  were  of  utmost  importance.  The  DP’s  that 
worked  on  the  OAIS  Help  Desk  resented  being  put  in  the 
position  of  answering  the  phone  and  dealing  with  frustrated 
users.  The  glamourous  positions  in  their  eyes  were  those  of 
Systems  Administration  and  the  Information  Center  in  N470. 
One  factor  that  may  have  assisted  in  facilitating  this 
change  in  direction  in  the  organization  would  have  been 
clear-cut,  mappe  -out  career  paths  for  the  DP's.  Employees 
are  motivated  when  there  is  a  clearly-defined  relation 
between  performance,  recognition  and  advancement  [Ref.  23 :p. 
42].  Instead  of  having  advancement  and  transfer  up  to  the 
discretion  of  top  management,  with  their  decisions  based 
upon  past  performance  cf  personnel,  designated  career  paths 
should  have  been  established.  When  career  paths  are 
documented,  personnel  are  motivated,  recruited  and  trained 
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in  accordance  with  their  desires  for  promotion  [Ref.  23 :p. 
41]  . 

c.  Pre-Implementation  Activities 

(1)  Lessons  Learned.  One  of  the  major  problems 
identified  with  the  implementation  of  OAIS  in  May  1986  was 
the  lack  of  testing.  In  May  1986  there  had  been  no 
integrative,  system,  nor  validation  testing  conducted.  All 
four  types  of  testing  were  conducted  for  this  implementation 
effort.  One  of  the  reasons  for  the  lack  of  testing  was  lack 
of  a  test  application.  A  test  application  was  available  for 
this  implementation  effort.  Also,  in  the  previous  implemen¬ 
tation,  the  programming  team  was  a  combination  of  Navy  Data 
Processing  Technicians  and  contractor  personnel.  Having  two 
groups  responsible  for  the  programming  required  a  lot  of 
coordination  and  planning.  For  this  implementation,  all 
programming  was  done  by  the  contractors.  After  the  failure 
of  the  OAIS  implementation  in  May  1986,  LT  Hopkins  said  she 
wanted  test  plans  made  up  for  every  screen,  program,  and 
module  of  OAIS.  These  test  plans  were  created  by  the 
contractor  and  reviewed  by  appropriate  Navy  personnel. 

(2)  Testing.  A  system  stress  test  was 
scheduled  for  a  Friday  afternoon  in  February.  An 
insufficient  number  of  users  participated  for  NMPC-47  to  be 
sure  how  the  system  would  react  when  a  full  load  of  users 
were  using  the  system.  Due  to  the  Information  Systems 
department  being  on  the  same  level  as  the  users  in  the 
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organization,  CAPT  Williams  was  able  to  intercede  with  the 
Admiral  of  NMPC-4  and  his  fellow  department  heads  and  get 
full  user  participation  for  a  second  systems  stress  test. 

Individual  module  testing  was  done  by  the 
contractors.  When  the  new  project  manager  for  the 
contractor,  V.  Hammer,  came  on-board,  her  first  concern  was 
for  the  lack  of  interface  (an  aspect  of  integrative  testing) 
testing  between  OAIS  and  its  interfacing  systems.  Interface 
testing  became  one  of  her  priorities.  The  interface  which 
she  had  no  control  over  was  the  Order  Production  Module 
(OPM) -OAIS  interface.  The  OPM  was  still  under  development 
at  the  time  of  interface  testing.  This  status  concerned 
both  V.  Hammer  and  LT  Hopkins.  Each  took  the  matter  to 
their  immediate  boss,  but  to  no  avail. 

Validation  testing  utilizing  the  test  plans 
and  OAIS  user  representatives  was  scheduled  for  the  six 
weeks  prior  to  implementation.  Validation  testing  was 
conducted  every  afternoon  for  these  six  weeks.  Problems 
detected  were  prioritized  either  for  correction  prior  to 
implementation  or  after  implementation.  The  contractor  had 
only  the  morning  hours  before  each  testing  session  to  work 
on  corrections  to  the  problems.  One  of  the  problems 
identified  with  new  system  implementation  is  having 
inadequate  time  to  test  [Ref.  13 :p.  123].  This  was 
definitely  the  situation  with  the  OAIS  implementation.  All 
the  personnel  involved  with  the  testing,  contractors,  LT 


132 


Hopkins,  LT  Perkins,  and  CDR  Hazel  did  not  think  OAIS  was 
ready  for  implementation.  There  were  too  many  problems 
which  needed  to  be  fixed  prior  to  implementation  in  addition 
to  the  lack  of  testing  of  the  OAIS  interface  with  the  OPM. 

During  the  OAIS  validation  testing,  more 
emphasis  and  personnel  were  added  to  the  OPM  project  on  both 
the  Navy  and  contractor  teams.  The  addition  of  extra  people 
to  a  project  has  been  shown  to  decrease  productivity  for  a 
short  time.  The  decreased  productivity  is  due  to  time 
needed  to  train  personnel,  familiarize  them  with  the  project 
and  the  increased  amount  c  time  spent  on  communication 
between  project  members. 

(3)  Training.  Training  of  users  and  operators 
of  the  computer  systems  is  also  an  important  part  of  pre¬ 
implementation.  Training  for  the  users  was  increased  over 
the  last  implementation  try.  Users  were  kept  informed  of 
changes  to  OAIS  by  way  of  OAIS  User  Bulletins  and  their  user 
representatives.  An  updated  OAIS  U-  r  Manual  was 
distributed.  The  user  representatives  were  the  users  that 
participated  in  the  validation  test  Through  their 
exposure  to  the  new  system,  they  would  be  able  to  assist 
other  users  in  their  departments.  The  OAIS  Help  Desk 
personnel  also  were  trained  by  having  access  to  the  test 
system  in  the  early  morning  hours  before  the  contractors 
used  it  to  correct  the  software  problems  discovered  in  the 
validation  testing.  Full  scale,  "hands-on"  training  of 
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users  did  not  take  place  due  to  non-availability  of  the  test 
application  during  normal  working  hours. 

Operator  training  was  planned  to  occur  by 
having  contractor  personnel  in  Scheduling  every  night  during 
the  first  few  weeks  of  the  new  implementation.  This  would 
familiarize  Scheduling  personnel  with  the  new  procedures  and 
potential  problems. 

(4)  Method  of  Conversion.  There  are  four 
methods  by  which  an  organization  can  convert  to  a  new 
computer  system:  direct  cutover,  parallel  conversion, 
staged  conversion  and  pilot  system.  Direct  cutover  is  when 
conversion  takes  place  all  at  once.  The  old  system  is 
terminated  and  the  new  one  is  put  in  operation  immediately. 
Direct  cutover  was  the  method  chosen  in  the  May  1986  OAIS 
implementation.  There  are  risks  to  this  method.  The 
primary  one  being  that  if  a  major  problem  is  discovered  with 
the  new  system,  it  may  cause  some  computer  downtime  for  the 
organization.  Advantages  to  this  method  include  a  lack  of 
transition  costs,  and  psychologically,  users  may  try  harder 
to  work  with  the  new  application  when  there  is  nothing  for 
them  to  fall  back  on.  Transition  costs  are  those  costs  in 
resources  (personnel,  computer  time)  incurred  from  running 
two  systems  at  the  same  time.  [Ref.  ll:p.  737] 

With  parallel  conversion,  both  the  new  and 
old  systems  are  operated  in  parallel.  The  advantages  to 
this  method  are  that  the  old  system  is  there  to  rely  on  in 
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case  problems  do  develop  with  the  new  system.  Disadvantages 
include  the  additional  costs  in  resources  of  running  and 
updating  two  systems.  Staged  conversion  is  essentially  the 
replacement  of  the  old  system  with  the  new  system  in  a 
gradual  manner.  The  advantage  to  this  method  is  having  the 
new  capabilities  of  the  new  version  while  still  retaining 
the  flexibility  to  cope  with  any  problems.  The  last  method 
is  by  use  of  a  pilot  system.  The  new  version  is  implemented 
in  only  one  division  within  the  organization.  This 
minimizes  the  risk  to  the  entire  organization  and  also 
provides  lessons  learned  to  facilitate  implementation  in 
other  parts  of  the  organization.  [Ref.  ll:p.  736] 

NMPC-47  chose  parallel  conversion  for  this 
implementation  of  OAIS.  They  possessed  the  additional 
computing  capacity  and  willingness  to  take  on  the  additional 
costs  of  resources  to  maintain  both  the  old  and  new 
versions.  There  were  several  reasons  for  their  choice  of 
parallel  conversion.  OAIS  users  had  a  significant  amount  of 
work  already  completed  in  OAIS  which  would  have  had  to  be 
redone  in  the  new  system.  It  was  determined  that  this  would 
be  detrimental  to  user  service  and  user  confidence.  Also, 
in  light  of  the  implementation  problems  in  May  1986,  there 
would  be  a  system  to  fall  back  on  without  any  system 
downtime  for  the  users.  To  ensure  that  users  did  not 
continue  to  use  the  old  system  unless  they  had  previous  work 
in  OAIS  JK,  several  of  the  screens  were  disabled. 
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(5)  Conclusions .  NMPC-47  improved  their  pre¬ 
implementation  planning  and  activities.  More  thorough 
testing  procedures  were  established  and  followed,  covering 
all  four  types  of  testing  necessary  to  inspect  all  aspects 
of  new  software.  Users  were  involved  with  the  testing 
through  the  use  of  test  plans.  More  training  of  both  users 
and  operators  was  conducted.  The  ultimate  state  for 
training  would  include  "hands-on"  training  for  all  the 
users,  but  this  was  unavailable  to  NMPC-47  due  to  the  time 
and  computer  resources  needed  by  the  contractors  to  fix 
trouble  reports  discovered  during  testing.  The  decision 
concerning  parallel  conversion  versus  the  direct  cutover 
method  was  also  a  more  cautious  decision  taking  into  account 
user  workload.  The  area  of  testing  remained  the  one  problem 
of  the  pre-implementation  activities.  Insufficient  time  was 
allotted  for  the  testing  and  sucsequent  fixing  of  trouble 
reports  needing  fixing  prior  to  implementation. 

Additionally,  problems  still  existed  with  the  OAIS-OPM 
interface,  which  was  the  most  crucial  of  all  the  OAIS 
interfaces  because  it  was  responsible  for  the  output  of  the 
application.  Insufficient  concern  was  allotted  to  the  OPM 
program  and  when  it  did  become  critical,  more  people  were 
added  to  the  project,  slowing  down  productivity. 
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F.  CASE  STUDY  FIVE  TEACHING  NOTE 

1 .  Questions 

What  caused  the  OAIS  problems? 

What  cnanges  snouid  have  been  planned? 

2 .  Case  Summary 

This  case  describes  the  problems  which  occurred 
after  the  re-implementation  of  OAIS  in  May  1987.  The 
majority  of  problems  encountered  were  with  the  OAIS-Order 
Production  Module  (OPM)  interface.  Other  problems 
associated  with  the  new  OAIS  were  accounting  data  problems, 
missing  orders,  incorrect  orders  and  difficulties  with  the 
Communication  Center.  The  OPM  took  the  place  of  AUTONOM. 
The  software  changes  this  move  necessitated  were  planned 
for.  The  administrative  changes,  which  primarily  affected 
the  production  portion  of  the  department,  were  not  planned 
for.  These  changes  dealt  with  maintenance  of  magnetic 
tapes,  increased  demand  for  the  letter  sorter  machine  and 
inadequate  reports  for  tracking  of  orders.  Top  management 
of  NMPC-47  and  the  contractors  got  heavily  involved  in 
solving  the  problems. 

3 .  Major  issues/Problems 

Interface  problems. 

Lack  of  planning. 

Top  Management  involvement. 
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4 .  Case  Analysis 

a.  Interface  Problems 

On  the  surface,  the  majority  of  the  problems 
with  OAIS  can  be  blamed  on  the  interface  between  OAIS  and 
the  OPM.  Problems  with  this  interface  were  identified 
during  execution  of  the  test  plan.  The  OPM  failed  all  its 
tests,  but  was  implemented  anyway.  The  OPM  was  identified 
as  a  critical  interface  approximately  three  months  before 
the  implementation  date.  Neither  the  Navy  nor  the 
contractor  project  management  team  increased  their  effort 
until  a  few  weeks  before  implementation.  The  additional 
personnel  added  to  the  project  only  slowed  down 
productivity.  This  was  due  to  the  increased  time  needed  to 
familiarize  the  personnel  with  the  project  and  for 
communication  among  project  members. 

Developing  the  OPM  was  an  accomplishment  of  the 
NMPC-47  long-term  goal  of  being  responsible  for  the  entire 
order  production  process.  The  OPM  did  not  just  produce 
officer  orders.  It  was  also  responsible  for  all  the  jobs 
previously  accomplished  by  AUTONOM.  AUTONOM  had  been 
responsible  for  producing  the  MPN  Financial  Management 
System  (MFS)  tape  sent  to  Navy  Finance  Center,  Cleveland 
with  the  accounting  data  and  cost  of  each  set  of  orders. 
AUTONOM  had  generated  reports  that  assisted  in  the  tracking 
of  orders.  AUTONOM  had  also  placed  OAIS  information  in  the 
proper  format  for  Naval  messages  or  letters.  It  is  obvious 


from  top  management's  decision  to  implement  the  OPM,  even 
though  it  had  failed  the  test  plan,  that  they  were  unaware 
of  all  the  possible  repercussions  of  implementing  the  OPM. 

Considering  the  six  causes  of  poor  performance 
on  projects  that  Russell  Archibald  has  compiled  (see  Case 
Study  Three  Teaching  Note) ,  the  overriding  general  cause  of 
the  OAIS  problems  was  a  lack  of  integrated  planning  and 
control.  Again,  as  in  the  previous  implementation  effort  in 
May  1986,  the  improperly  introduced  matrix  structure  for 
project  development  is  the  root  of  the  problems  encountered. 
The  project  officer  focus  as  on  the  software  changes  in 
OAIS,  not  on  the  changes  which  would  be  required  of  the 
entire  organization  to  use  the  new  OAIS.  An  information 
system  is  not  just  software.  It  also  includes  hardware, 
procedures,  people  and  an  applicable  organization  structure. 
With  a  system  like  OAIS  that  has  far-reaching  effects  both 
on  other  organizations  and  on  which  users  are  heavily 
dependent,  additional  planning  is  needed.  Additional 
planning  in  the  form  of  establishing  an  interface  with  the 
OPM  project  officer  from  an  early  sage  in  the  project  and 
having  an  integrated  project  team  consisting  of  development 
and  production-oriented  personnel  was  needed.  These 
^asures  would  have  helped  to  prevent  some  of  the  problems, 
b.  Lack  of  Planning 

An  integrated  project  team  could  possibly  have 
foreseen  the  following  production-oriented  problems:  order 


139 


tracking  and  accounting,  output  verification,  liaison  with 
the  Communication  Center  and  condition  of  the  letter  sorter 
machine.  The  capability  of  tracking  and  accounting  of 
orders  could  have  been  built  into  the  reports  generated  for 
the  OAIS  Help  Desk.  Personnel  performing  verification  of 
OPM  output  could  have  been  trained  and  the  new  job 
descriptions  could  have  been  viewed  with  anticipation.  An 
increase  in  duties  to  include  liaison  with  the  Communication 
Center  could  have  been  an  increase  in  responsibility  and 
morale  for  personnel  at  the  OAIS  Help  Desk.  With  some 
advance  planning,  a  good  working  relationship  could  have 
been  established  with  the  Communication  Center  prior  to  OAIS 
implementation.  Having  foreseen  possible  problems  with  the 
magnetic  tapes,  a  standard  run  book  procedure  could  have 
been  established  for  Scheduling.  A  new  letter  sorter  o-»- 
supplementary  maintenance  of  the  old  one  could  have  been 
arranged  in  advance.  A  contingency  plan  could  have  been 
developed  to  provide  for  breakdowns. 

NMPC-47  was  faced  with  both  computer-oriented 
problems  and  organization  problems  due  to  the  implementation 
of  OAIS.  These  problems  were  addressed  and  dealt  with  only 
in  terms  of  expediency.  The  civil  servants  in  N472  were 
delegated  the  job  of  verifying  the  orders  that  OAIS 
generated.  This  was  an  added  burden  for  these  personnel  and 
decreased  their  morale.  Since  the  letter  sorter  was  down  so 
often,  enlisted  personnel  had  to  spend  several  hours  a  day 
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sorting  letters  by  hand  and  preparing  them  for  mailing.  The 
job  of  liaison  with  the  Communications  Center  was  given  to 
the  OAIS  Help  Desk.  If  a  problem  was  discovered  with  the 
daily  magnetic  tapes,  the  contractors  had  to  be  called  to 
redo  the  tape  or  part  of  the  tape.  This  took  time  away  from 
fixing  the  software  problems. 

A  problem  with  OAIS  that  was  not  caused  due  to  a 
lack  of  testing  were  the  enhancements  made  to  OAIS  JK  that 
were  not  a  part  of  OAIS  1.7.  These  were  changes  made  by  the 
Applications  Programming  Shop.  These  changes  were  not 
documented  in  the  application  documentation.  Having  them 
missing  from  the  new  version  was  again  an  example  of  a  lack 
of  integrated  planning  and  control, 
c.  Top  Management 

Top  management  of  both  NMPC-47  and  the 
contractor  got  involved  to  solve  the  crisis.  Meetings  were 
held  three  times  a  week  with  management  and  technical 
personnel.  Top  management  assigned  priorities  and  due  dates 
for  individual  problems.  LT  Hcpkins  was  taken  out  of  the 
OAIS  project.  LT  Perkins  and  CDR  Hazel  took  control  of  day- 
to-day  activities  and  correction  of  OAIS  and  OPM  trouble 
reports.  Top  management  became  involved  in  the  details  of 
daily  OAIS  production  and  long  range  plans  for  correction  of 
trouble  reports.  Their  computer  expertise  contributed  some 
much  need  direction  to  the  OAIS  project.  This  crisis  paved 
the  way  for  NMPC-47  management  to  realize  that  their 
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information  systems  did  not  exist  in  a  vacuum.  Information 
systems  had  become  an  integral  part  of  the  NMPC  mission. 

G.  CASE  STUDY  SIX  TEACHING  NOTE 

1 .  Questions 

How  do  you  evaluate  CAPT  Hampton's  changes? 

What  are  the  signs  of  NMPC-47  maturity? 

-  How  would  you  deal  with  the  new  contractors? 

2 .  Case  Summary 

This  case  study  addresses  the  timeframe  of  May  1987 
through  November  1987.  NMPC-47  is  slowly  recovering  from 
the  problems  generated  by  implementation  of  an  inadequately 
tested  application.  The  focus  of  the  organization  is  on 
regaining  user  confidence  and  fixing  production-oriented 
problems.  A  new  contractor  has  just  been  awarded  the 
maintenance  contract  for  OAIS.  A  new  department  head  makes 
changes  in  the  organization  structure  and  implements  changes 
to  administrative  policies.  The  information  systems 
organization  and  its  users  have  matured.  Users  have  an 
interest  in  daily  activities  and  a  vote  on  the  priorities  of 
application  enhancements.  A  steering  committee  for  NMPC-47 
is  formed  to  ensure  compatibility  of  future  plans  for  NMPDS 
and  resource  sharing.  NMPC-47  has  acquired  sufficient 
functional  expertise  and  computer  savvy  to  be  directing 
computer  systems  management  with  the  contractors  in  an 
assistant  role. 
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3 .  Major  Issues/Problems 

Integration  of  information  system  into  organization. 

Data  is  a  resource. 

Maintenance. 

Documentation. 

Standards  and  Quality  Assurance. 

User  Responsibility. 

4 .  Case  Analysis 

a.  Nolan's  Stages  of  Growth 

NMPC-47's  information  systems  and  management  are 
now  in  the  beginning  of  the  Data  Resource  Function  stage, 
stage  five.  Characteristics  of  this  stage  exhibited  by 
NMPC-47  are  consideration  of  data  as  a  resource, 
consideration  of  applications  as  valuable  assets  and 
integration  of  information  systems  into  the  organization. 
Also,  managers  are  experienced  in  information  systems  and 
computing  issues.  [Ref.  ll:p.  674] 

(1)  Data  is  a  Resource.  The  establishment  of 
the  Configuration  Control  Board  (CCB)  is  an  indicator  that 
NMPC-47  views  data  as  a  resource.  This  board  is  composed  of 
functional  managers,  top  management,  technical  experts  and 
staff  personnel  from  within  NMPC-47.  The  focus  of  the  CCB 
is  on  planning  for  the  future,  ensuring  compatibility  of 
data  and  requirements  for  the  four  applications  within  NMPDS 
and  resource  sharing.  The  CCB  reviews  any  changes,  both 
short  and  long  term,  prior  to  implementation. 
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The  fact  that  applications  are  viewed  as 
valuable  assets  in  themselves  is  supported  by  two  factors. 
One  is  the  emphasis  and  time  given  to  maintenance  of  OAIS. 
Placing  an  emphasis  on  maintenance  expresses  an  evolutionary 
attitude  concerning  the  importance  of  the  information 
systems.  Maintenance  is  the  gradual  upgrading  and 
implementing  of  user  and  technical-oriented  changes.  This 
gradual  process  provides  for  economies  of  scale  and  long 
term  efficiencies  versus  letting  the  system  get  outdated  and 
having  the  large  expense  of  developing  from  scratch  [Ref. 
20:p.  11].  "The  updating  of  existing  systems  and 
capabilities,  the  balancing  of  stability  with  a  degree  of 
change  can  be  an  important  measure  of  financial  and 
operational  success  and  of  “he  maturity  of  the  organization 
itself."  [Ref.  20:p.  10] 

In  addition  to  maintenance,  time  is  also 
needed  to  regain  user  confidence  in  OAIS.  This  confidence 
can  be  restored  by  a  steady  track  record  of  implementing 
fixes  to  problems  caused  by  the  0PM  and  fixes  to  problems, 
such  as  PRD  inconsistencies,  that  have  existed  for  some 
time.  By  allocating  all  six  contractor  personnel  to 
maintaining  OAIS,  this  goal  is  possible.  Additionally, 
allowing  for  maintenance  time  gave  the  new  contractors  time 
to  understand  the  processes  and  programs  of  the  OAIS 
application.  This  education  will  help  facilitate  the 
implementation  of  enhancements  in  the  future.  This  time  for 
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education  is  essential  considering  the  poor  condition  of 
OAIS  documentation.  There  is  a  cost  to  this  emphasis  on 
maintenance  and  re-establishing  user  confidence  and  that  is 
application  enhancements.  Top  management  realized  that  with 
a  new  contractor,  poor  documentation,  disappointed  users  and 
an  unsteady  OAIS  foundation  that  the  chances  of  problems 
with  new  enhancements,  such  as  the  problems  experienced  with 
the  activity  file,  are  likely.  The  benefits  of  taking  this 
extra  time  will  pay  off  in  the  future  when  the  development 
of  future  enhancements  takes  less  time  and  resources. 

(2)  Documenta  ion.  OAIS  documentation  had  been 
of  poor  quality  since  the  inception  of  the  project  in  1932. 
Problems  caused  by  this  poor  quality  of  documentation  had 
not  been  encountered  previous  to  this  time  for  several 
reasons.  One,  the  same  contractor  that  had  developed  the 
original  documentation  and  program  code,  still  had 
responsibility  for  the  project.  Two,  the  changes  being  made 
to  OAIS  were  primarily  centered  arou.  1  conversion  of  the 
software  version  and  total  redesign  of  certain  interfaces 
such  as  the  OPM  and  orderwriting  itu  ule.  With  a  new 
contractor  taking  over  the  OAIS  project  there  was 
unfamiliarity  with  the  functions  of  the  application  as  well 
as  with  the  code.  Adequately  maintained  documentation  could 
have  assisted  the  new  contractor,  instead  of  causing  them 
problems. 

Documentation  of  information  processing  can  provide  the 

following  benefits:  (1)  content  and  format  guide  for 


145 


documentation  of  data  processing  procedures,  policies, 
practices  and  requirements?  (2)  complete  record  of  an 
information  processing  system  from  analysis  through 
implementation  and  maintenance;  (3)  data  for  simplifying 
and  facilitating  either  conversion  to  new  or  upgraded 
hardware  and  or  software  or  adoption  of  a  new  application; 
(4)  communication  medium  for  transfer  of  information. 

[Ref.  24 :p.  121] 

The  new  contractor's  initial  tasking  was  to 
correct  all  the  problems  with  the  OPM  and  production  OAIS. 
This  is  where  the  documentation  was  needed,  to  try  to 
understand  the  intent  and  content  of  the  program.  It  became 
evident  at  this  point  that  the  documentation  had  also  not 
been  kept  up-to-date.  These  problems  with  documentation, 
particularly  the  reporting  and  recordkeeping  fall  under  the 
function  of  quality  assurance. 

(3)  Standards  and  Quality  Assurance.  The 
second  factor  illustrating  the  organizations ' s  view  of  the 
application  as  a  valuable  resource  is  the  emphasis  on 
standards.  Standards  for  documentation,  operating 
procedures  and  programs  have  existed  since  the  establishment 
of  NMPC-47.  Configuration  Management  was  responsible  for 
making  and  distributing  the  policy  on  standards  for 
organization  and  contractor  use.  Prior  to  this  time  period, 
however,  the  organization  emphasis  was  on  development.  The 
extra  time  was  not  taken  to  ensure  adherence  to  standards  in 
the  rush  to  get  an  application  to  the  users.  Once  there  was 
time,  the  problem  seemed  too  hard  and  there  were  other 
pressing  matters.  It  was  not  until  NMPC-47  and  the  new 
contractors  themselves  experienced  problems  with  the  non- 
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documented  software,  that  standards  became  the  answer  to 
their  problems. 

Standards  are  important  for  the  following 
reasons:  they  are  a  basis  of  communications,  so  that  all 

involved  are  talking  the  same  language,  they  ensure 
compliance  with  policies  and  practices  and  they  minimize  the 
effects  of  changes  [Ref.  24 :p.  108].  Standards  are  a  part 
of  preventive  management.  Having  a  quality  assurance 
function  within  the  project  structure  in  also  preventive 
management . 

Quality  assurance  comprises  a  variety  of  tasks...: 

(1)  application  of  technical  methods,  (2)  conduct  of 
formal  technical  reviews,  (3)  testing  of  software,  (4) 
enforcement  of  standards,  (5)  control  of  change,  (6) 
measurement,  and  (7)  recordkeeping  and  reporting.  [Ref. 

12 :p.  438] 

Quality  assurance  is  built  into  the 
functions  of  an  information  systems  department  by  the 
establishment  and  documentation  of  control  systems  and 
procedures  which  are  responsible  for  monitoring  quality 
[Ref.  20:p.  151].  NMPC-47  implemented  the  quality  assurance 
functions  by  having  the  OAIS  Help  Desk  review  and  certify 
the  work  done  by  the  contractor  and  by  the  adherence  to 
standards.  Prior  to  this  period,  the  work  of  the  contractor 
was  not  verified  nor  evaluated  to  ensure  compliance  with  the 
standards.  A  change  to  production  control  procedures  was 
implemented  for  quality  assurance  purposes.  Production 
Control  personnel  were  made  responsible  for  reviewing  the 
run  books  and  program  naming  conventions  to  ensure  their 
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feasibility  and  adherence  to  standards.  This  review  was 
required  prior  to  implementation.  The  review  time  added  a 
few  days  onto  the  implementation  of  fixes,  but  in  the  long 
run  would  save  time  by  having  standardized  procedures. 
NMPC-47  had  a  long  way  to  go  until  quality  assurance  was  a 
part  of  every  application  and  program,  but  they  have  started 
a  program  to  work  towards  that  goal. 

Quality  assurance  and  utilization  of 
standards  minimize  the  effects  of  change  on  the  application. 
Change  is  inevitable  in  a  computer  system.  Changes  are 
needed  to  correct  errors,  incorporate  user  requests  for 
enhancements  and  to  take  advantage  of  technology 
advancements  [Ref.  ll:p.  605].  By  minimizing  the  effects  of 
change,  the  quality  of  maintainability  is  enhanced. 
Maintainability  is  defined  by  Roger  Pressman  as  the  ease 
with  which  software  can  be  understood,  corrected,  adapted, 
and/or  enhanced  [Ref.  12:p.  531].  The  concept  of 
maintainability  supports  the  design  ion  of  an  application 
as  a  valuable  resource  and  that  maintenance  is  part  of  an 
evolutionary  approach  to  information  systems  planning. 

(4)  User  Responsibility.  The  managers  of  NMPC- 
47  are  now  experienced  veterans  of  information  systems 
development  and  computing  requirements.  A  lot  of  lessons 
were  learned  the  hard  way  and  at  user  expense,  but  the 
experience  and  lessons  learned  have  been  effective.  This 
growth  in  expertise  is  evident  in  several  ways: 
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establishment  of  the  CCB,  adherence  to  standards,  use  of 
requirements  analysis  for  OPM  fixes,  and  establishing  a 
quality  assurance  review  for  contractor  fixes.  Another  way 
the  experience  is  evident  is  making  the  user  more 
responsible  for  OAIS.  The  requirements  of  training  prior  to 
issuance  of  a  password  and  mandatory  attendance  at  user 
meetings  were  designed  to  make  the  users  the  driving  force 
behind  OAIS.  By  requiring  the  training  of  all  users,  NMPC- 
47  built  user  confidence  [Ref.  209:p.  54].  This  user 
education  covered  all  aspects  of  the  application  and  with 
this  knowledge  comes  a  sense  of  ownership,  confidence, 
responsibility  and  interest. 

b.  Organization  Changes 

When  Captain  Hampton  reported  on-board,  he  made 
several  changes  to  the  organization  structure  of  NMPC-47. 

He  further  refined  NMPC-47  so  that  its  branches  were  in 
alignment  with  the  three  functions  and  two  support  functions 
suggested  for  an  information  systems  department.  These 
three  functions  are  development,  maintenance  and  production. 
The  two  support  functions  are  administrative  and  technical. 

A  discussion  of  these  areas  is  in  the  Case  Study  Four 
Teaching  Note. 

The  customer  support  task  within  the  technical 
support  function  was  centralized  further  with  the  move  of 
Order  Support  personnel  in  N472  to  N471.  The  Information 
Systems  Support  branch,  N471,  now  included  all  customer 
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oriented  interfaces.  The  function  of  production  control  was 
broken  out  from  under  Systems  Administration.  This  move  was 
in  recognition  of  its  importance  to  the  organization.  With 
this  change,  problems  which  had  existed  for  some  time  were 
able  to  reach  top  management.  One  of  these  problems 
involved  report  distribution  and  had  brought  on  a  Naval 
Audit  investigation  concerning  wasted  paper.  Further,  the 
lack  of  adherence  to  standards  was  brought  out  in  the  open 
and  the  CCB  acted  on  this  deficiency.  An  information 
systems  policy  and  procedures  branch  was  created.  This 
branch  contained  portions  of  the  technical  and 
administrative  support  functions.  Configuration  Management 
and  Data  Administration  were  placed  in  this  branch.  This 
consolidation  created  a  division  responsible  for  controlling 
the  assessing  the  applications  in  NMPDS  and  planning  for 
their  future. 

c.  New  Contractors 

NMPC-47  top  management  is  impressed  with  the 
honesty  and  technically  proficient  explanations  they  receive 
from  the  new  contractors,  SYSCON.  With  the  decision  to  put 
all  six  programmers  to  work  fixing  production  problems,  the 
active  implementation  of  standards  for  configuration 
management  and  establishment  of  a  quality  assurance 
function,  NMPC-47  is  in  an  excellent  position  to  ensure  the 
quality  of  contractor  work.  Additionally,  these  efforts 
will  assist  in  returning  the  OAIS  project  back  to  its  good 


150 


reputation  with  the  users.  By  having  the  CCB  performing  its 
function  of  ensuring  compatibility  and  resource  sharing  for 
NMPDS  and  the  contractor  being  required  to  explain  the 
reasons  behind  both  short  and  long  term  fixes,  NMPC-47  has 
taken  steps  to  guard  against  the  problems  caused  by  total 
reliance  on  a  contractor. 

There  are  two  suggestions  to  ensure  the 
continued  viability  of  OAIS.  One  is  that  as  the  contractors 
progress  through  fixing  production-oriented  problems,  NMPC- 
47  direct  them  and  provide  the  time  and  money  for  updating 
the  system  documentation.  This  will  assist  with  future 
implementation  efforts  and  the  move  toward  redesign  of  OAIS 
into  a  database  oriented  application.  The  second  suggestion 
concerns  project  management.  The  OAIS  project  officer 
should  acquire  some  functional  expertise  with  OAIS  and 
utilize  an  integrated  project  development  team  composed  of 
production  and  maintenance  technically  proficient  personnel 
for  planning  future  development  eff^.cs. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

1 .  Research  Question  One 

The  conclusion,  in  regard  to  the  first  research 
question  concerning  what  could  have  done  to  prevent  the 
problems  from  occurring  with  OAIS,  is  still  ambiguous. 
Prevention  of  problems  like  those  experienced  with  OAIS  can 
only  occur  through  adherence  to  established  standards  and 
procedures  for  documentation,  testing,  and  quality 
assurance.  Following  through  with  these  activities 
throughout  the  life  cycle  of  OAIS  will  facilitate  the 
implementation  of  future  changes  and  help  ensure  that  the 
maintenance  phase  tasks  are  easier.  This  experience  with 
OAIS  and  the  subsequent  analyses  of  this  case  study  has 
assisted  in  the  identification  of  possible  causes  of 
problems  during  information  systems  development.  This 
knowledge  will  be  of  value  in  the  future  to  help  identify 
potential  problem  situations  before  they  turn  into  full¬ 
blown  problems. 

The  possible  causes  of  problems  pertaining  to  OAIS 
development  include  the  following:  (1)  acceptance  of  poor 
quality  documentation;  (2)  implementation  of  the  prototype; 
(3)  failure  to  adhere  to  standards;  (4)  lack  of  testing;  and 
(5)  lack  of  quality  assurance  activities.  The  problems 
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caused  by  the  acceptance  of  poor  quality  documentation  and 
implementation  of  the  prototype  had  been  put  in  motion  by 
actions  taken  at  the  beginning  of  the  OAIS  life  cycle. 

Documentation  is  viewed  by  the  majority  of  software 
developers  as  a  peripheral  activity.  Yet,  documentation  is 
essential  for  the  performance  of  maintenance  activities  in 
the  future.  The  documentation  received  on  the  Officer 
Assignment  Information  System  (OAIS)  was  of  poor  quality. 

In  addition,  the  documentation  suffered  from  a  lack  of 
updating  as  changes  were  made  and  maintenance  activities 
performed.  It  was  not  until  a  new  contract  for  OAIS 
maintenance  was  awarded  in  1987  that  the  full  effects  of  the 
poor  quality  of  documentation  were  felt  by  NMPC-47.  The 
contractors  required  extra  time  to  understand  the  OAIS 
programs  while  trying  to  fix  software  trouble  reports.  This 
extra  time  took  resources  away  from  implementing  user 
requested  software  enhancements. 

Implementation  of  the  prototype  has  been  documented 
as  a  dangerous  problem  when  utilizing  the  prototyping 
development  methodology.  This  problem  has  been  noted 
particularly  in  situations  where  users  are  unhappy  with 
their  present  system.  This  was  the  case  with  NMPC. 

Problems  had  existed  with  the  assignment  process  r-ince  the 
late  1970's.  OAIS  drastically  improved  the  assignment 
process  in  comparison  to  the  manual  system.  NMPC-47  yielded 
to  user  pressure  and  implemented  the  prototype.  It  is  easy 
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to  see  why  NMPC-47  made  the  decision  to  implement  the 
prototype.  Implementation  of  the  prototype  was  a  sensible 
public  relations  move.  Users  loved  OAIS  and  the  publicity 
OAIS  received  within  the  organization  made  those  departments 
that  were  not  on-line  yet,  want  OAIS  as  soon  as  possible. 
This  positive  attitude  would  facilitate  future 
implementation  efforts.  Additionally,  as  prototyping  was  on 
the  leading  edge  of  technology,  there  was  little  information 
concerning  the  pros  and  cons  of  prototype  implementation  to 
guide  NMPC-47. 

By  implementing  the  prototype,  NMPC-47  also  set 
themselves  up  for  efficiency  and  maintenance  problems  in  the 
future.  The  prototype  is  developed  rapidly  with  concern 
only  for  the  output,  not  how  the  output  is  generated.  There 
exists  the  possibility  of  compromises  and  inefficiencies  in 
the  implementation  of  the  inner  workings  of  the  prototype. 
Though  not  explicitly  stated  as  reasons  for  the  problems 
with  the  OAIS  versions  implemented  in  1986  and  1987,  the 
inefficiencies  in  the  development  of  the  original  prototype 
played  a  significant  role. 

2 .  Research  Question  Two 

A  second  research  question  addresses  explanations 
for  problems  encountered  in  OAIS  implementation  efforts.  In 
addition  to  the  impact  of  the  implementation  of  the 
prototype  mentioned  above,  the  underlying  factor  which 
contributed  to  the  problems  encountered  with  both  of  the 
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OAIS  implementation  efforts  in  May  1986  and  May  1987  was  the 
project  management  function. 

NMPC-47  managed  application  development  with  a 
project  officer  and  a  matrix  structure  for  liaison  between 
project  management  and  functional  management.  The 
organization  was  not  properly  prepared  to  accept  matrix 
management.  Personnel  must  be  educated  and  procedures  and 
behaviors  must  be  changed  in  order  for  the  matrix  to 
function  properly.  Most  people  are  familiar  with  the  "one 
person-one  boss"  tradition.  Switching  over  to  being 
responsible  to  two  bosses,  in  this  case  a  project  manager 
and  a  functional  manager,  involves  stress  and  uncertainty 
for  the  personnel  concerned.  The  project  management 
function  worked  successfully  in  the  matrix  structure  during 
the  initial  development  and  deployment  of  OAIS.  During  this 
timeframe  a  production  version  of  OAIS  and  involved 
functional  management  did  not  exist.  For  the  implementation 
efforts  in  May  1986  and  1987,  a  production  version  of  OAIS 
with  approximately  330  users  and  functional  management 
concerned  for  its  continued  operation  did  exist.  This 
caused  conflicts  regarding  the  scheduling  of  manpower  and 
computer  resources. 

A  contributing  factor  to  the  implementation  problems 
was  a  lack  of  integrated  planning  and  control  by  the  project 
manager  for  implementation  of  the  new  version.  The  project 
manager  for  OAIS  was  inexperienced  in  the  software 
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development  field.  Her  inexperience  combined  with  a  lack  of 
managerial  skills  contributed  to  a  lack  of  integrated 
planning  and  control.  One  manifestation  of  this  lack  of 
planning  and  control  was  a  lack  of  testing  prior  to 
implementation.  In  1986,  there  was  no  integration, 
validation  nor  systems  test  of  the  entire  application.  If 
these  tests  had  been  conducted  prior  to  implementation,  OAIS 
would  not  have  been  implemented.  Another  factor  was  a  lack 
of  planning  for  changes  other  than  software  changes  caused 
by  implementation  of  a  new  version  of  OAIS.  In  May  1987, 
NMPC-47  became  responsible  for  the  entire  order  production 
process,  taking  over  responsibility  for  a  variety  of  tasks 
dealing  with  verification  and  generation  of  output.  These 
changes  were  not  planned  for  and  subsequently  caused 
significant  problems  within  the  organization  and  among  the 
users . 

B.  LIMITATIONS  OF  THE  STUDY 

This  case  study  dealt  with  one  organization  within  the 
U.S.  government.  NMPC  is  a  Navy  Headquarters  command  and 
the  constraints  under  which  it  operates  may  not  apply  to  a 
lower-echelon  command.  Additionally,  the  computer 
application  was  developed  using  a  prototyping  development 
methodology  and  a  third  generation  software  language. 

Factors  and  events  deemed  important  using  this  methodology 
and  software  language  many  not  apply  to  another  type  of 
methodology  and  software  language.  A  further  limitation 
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concerns  the  distribution  of  the  computer  application.  OAIS 
was  developed  and  utilized  in  one  geographic  location  for  a 
centralized  group  of  users.  Computer  applications  developed 
for  distribution  to  several  commands  and  spread  over  several 
geographic  locations  may  not  encounter  the  problems  and 
events  stated  in  this  case. 

Cf  particular  note  is  the  contrast  between  public  (U.S. 
government)  and  private  industry.  The  limitations  imposed 
on  the  U.S.  government  include  budget  restrictions,  full  and 
open  competition  (when  applicable)  and  bureaucratic 
practices  for  the  approval  of  change.  These  practices  take 
excessive  amounts  of  time  Private  industry  does  not 
function  under  the  same  type  of  limitations.  If  changes  are 
required,  they  occur  rapidly.  If  a  particular  product  or 
company  is  preferred,  private  industry  can  choose  it.  The 
method  or  solution  that  a  U.S.  government  agency  may  invoke 
is  limited  by  the  above-stated  restrictions.  The  method  to 
correct  a  situation  such  as  that  of  NMPC  may  differ 
depending  on  whether  it  is  a  U.S.  g  vernment  agency  or 
private  industry. 

C.  FUTURE  RESEARCH 

In  addition  to  documenting  a  situation  where  the  leading 
edge  of  technology  was  an  issue,  this  case  also  dealt  with 
implementation  of  the  computer  application  and  its 
associated  decisions  and  problems.  The  Computer  Systems 
Management  curriculum  includes  education  on  software 
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development  principles  and  practices.  There  is  little 
emphasis  on  the  implementation  side  of  the  computer 
application.  A  recommended  area  for  future  research  is  an 
analysis  of  the  feasibility  of  including  implementation- 
oriented  material  within  the  curriculum. 


D.  RECOMMENDATIONS 

1 .  Redesign  of  PAIS 

In  accordance  with  the  problems  encountered  with 

prior  OAIS  implementation  efforts,  the  following 

recommendations  are  suggested  for  NMPC ' s  redesign  of  OAIS: 

Ensure  complete  and  up-to-date  documentation  is 
available  on  OAIS  programs  and  interfaces. 

Utilize  development  personnel  and  programmers  who  are 
experienced  with  the  particular  database  package 
chosen. 

Plan  for  and  follow  through  on  extensive  testing  of  all 
four  types.  Plan  for  testing  and  error  correction  to 
proceed  at  a  normal  workday  (eight  hours)  pace  of 
operations  by  allowing  extra  time  for  testing. 

Educate  and  train  OAIS  users  thoroughly  prior  to 
implementation.  Hands-on  training  is  the  most 
effective.  If  the  users  comprehend  the  changes  being 
made,  they  will  be  more  tolerant  of  any  errors  that  may 
be  detected  once  the  application  is  implemented. 

Don't  let  the  political  pressures  of  a  headquarters 
environment  allow  implementation  of  an  application  that 
is  not  ready.  This  short-term  decision  will  only  cause 
long-term  problems  and  cost  more  in  terms  of  resources 
in  the  long  run. 

2 .  Case  Studies 


Very  few  of  the  students  who  come  to  the  Naval 
Postgraduate  School  have  had  any  experience  with  development 
or  implementation  of  computer  applications.  The  basic 
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principles  and  procedures  of  software  development  are 
included  in  the  curriculum.  To  a  limited  extent,  some 
experience  with  software  development  is  gained  through 
experience  with  group  projects.  This  experience  is 
primarily  in  the  field  of  microcomputer  applications. 
Additional  experience,  whether  real  or  the  simulated 
experience  of  a  case  study,  covering  the  areas  of  software 
development  within  the  Department  of  Defense  and  in  a 
mainframe/minicomputer  environment  are  needed.  This 
experience  can  assist  students  when  they  are  confronted  with 
a  similar  situation  once  they  leave  school.  One  of  the 
primary  figures,  the  project  officer,  in  this  case  study  was 
a  Naval  Postgraduate  School  graduate.  To  ensure  that 
graduates  of  the  Computer  Systems  Management  curriculum  do 
not  make  the  same  mistakes  due  to  the  lack  of  experience, 
there  needs  to  be  a  stronger  emphasis  on  change  and 
implementation  issues  in  Department  of  Defense 
organizations . 
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APPENDIX  A 


PAIS  INTERFACES 


OAIS  interfaces  with  eight  external  applications  and  one 
internal  (N47-managed)  application.  The  internal  computer 
system  is  the  On-Line  Distribution  Information  System 
(ODIS) .  ODIS  is  a  database  system  and  uses  a  Model  204  Data 
Base  Management  System  (DBMS) .  OAIS  provides  daily  or 
weekly  updates  of  the  personnel,  billet  and  activity  files 
to  ODIS.  ODIS  does  not  pass  any  data  back  to  OAIS. 

The  Officer  Master  File  (OMF)  is  the  primary  repository 
of  personnel  data  on  all  active-duty  officers.  The  OMF  is 
managed  by  NMPC-16.  Every  night  an  OMF  change  tape  is  run 
to  update  OAIS.  Changes  generated  within  OAIS  during  the 
day  are  provided  via  magnetic  tape  to  update  the  OMF. 

Changes  generated  within  OAIS  include  PRD  changes, 
submarine/aviation  pay  changes,  and  order  information. 

The  orderwriting  system  used  until  May  1987  was  AUTONOM. 
AUT0N0M  was  managed  by  NMPC-16.  In  addition  to  producing 
the  officer  orders  for  distribution  to  the  fleet  either 
through  message  or  letter,  AUTONOM  also  interfaced  with  the 
Officer  Master  File  and  the  MPN  Financial  Management  System 
(MFS) 

When  AUTONOM  was  run,  it  was  sorted  against  the  Officer 
Master  File  which  verified  order  number,  order  modification 
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number,  and  detaching  UIC  information  between  OAIS  and  the 
OMF.  If  what  was  on  OAIS  did  not  correspond  with  the  data 
on  the  OMF,  the  order  became  an  AUTONOM  Reject.  Whether  the 
orders  were  generated  or  rejected,  AUTONOM  provided  OAIS 
with  a  transaction  tape  on  a  daily  basis.  This  tape  was 
used  to  update  order  status  information  with  the  date 
transmitted  in  the  case  of  order  generation,  or  in  the  case 
of  order  rejection,  to  pass  the  orders  back  up  the  automated 
chop  chain  for  further  work. 

The  MPN  Financial  Management  System  (MFS)  tape  was 
generated  during  AUTONOM  processing.  The  MFS  tape  contained 
projected  order  costs  for  training  and  travel  by  individual 
SSN .  This  tape  was  sent  to  Naval  Finance  Center  Cleveland 
on  a  daily  basis  by  NMPC-16  and  hard  copy  was  provided  to 
NMPC-7  for  verification. 

The  Order  Production  Module  (OPM)  took  the  place  of 
AUTONOM  in  May  1987.  The  OPM  was  managed  by  NMPC-47  through 
the  Scheduling  Shop.  The  OPM  was  originally  designed  for 
use  with  the  Enlisted  Assignment  Information  System,  but  was 
used  with  OAIS  when  a  common  order  format  was  agreed  upon 
between  officer  and  enlisted  distribution  communities. 

The  Navy  Manpower  Data  Accounting  System  (NMDAS)  is 
managed  by  OP-01.  Information  concerning  organizational 
manning  totals,  personnel  and  billet  authorizations,  and 
billet  phasing  dates  is  contained  within  NMDAS.  Weekly 
changes  to  the  database  were  provided  via  magnetic  tape  to 
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OAIS .  These  changes  were  of  significant  importance  in 
assigning  officers. 

The  Officer  Fitness  Keport  File  (FITREP)  is  the 
responsibility  of  NMPC-3  and  operated  by  NMPC-16.  Condensed 
statistical  fitness  report  information  by  individual  Social 
Security  Number  (SSN)  is  contained  in  this  system.  Twice  a 
month,  updates  from  this  system  were  provided  to  OAIS. 

The  Automated  Detailing  Instruction  System  (ADIS)  was 
managed  by  NMPC-16.  This  system  contained  orderwriting  and 
specific  detailing  instructions  for  each  Navy  activity. 

This  information  was  updated  in  OAIS  via  magnetic  tape  twice 
a  month . 

The  Activity  File  was  managed  by  the  Enlisted  Personnel 
Management  Center  ( EPMAC) .  Information  such  as  accountable 
Personnel  Support  Detachment  Activities,  Ship  Deployment 
Dates,  Command  phone  numbers  and  addresses  were  provided  for 
each  Naval  activity.  This  information  was  updated  once  a 
month  before  May  1987  and  once  a  week  after  May  1987. 

The  Officer  Candidate  Accounting  and  Reporting  System 
(OCARS)  was  managed  by  NMPC-16.  OCARS  contained  information 
on  Officer  Candidates  which  was  needed  for  initiating  their 
first  set  of  orders.  Information  contained  in  this  system 
was  obtained  from  the  Naval  Recruiting  Command  or  the  U.S. 
Naval  Academy.  This  information  was  updated  in  OAIS  via 
magnetic  tape  once  a  month. 
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The  Navy  Information  Training  System  (NITRAS)  was  the 
responsibility  of  the  Chief  of  Naval  Education  and  Training 
(CNET) .  Information  pertaining  to  course  schedules, 
convening  dates  and  course  quotas  was  contained  on  this 
system.  Updates  were  provided  to  OAIS  on  a  weekly  basis. 
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APPENDIX  B 


TIMELINES  AND  PERSONNEL  LISTS 


List  of  Personnel 

October  19  8  5  -  May  1986 


Name 

Position 

Capt  Williams 

N-4 7  Department  Head 

Cdr  Rice 

N-470  Branch  Head 

Cdr  Zeke 

Previous  OAIS  Project  Officer 

Cdr  Cinder 

Previous  N-471  Branch  Head 

Cdr  Griffin 

N-4 71  Branch  Head 

Cdr  Hazel 

Previous  Training  Officer 

N-4 72  Branch  Head 

It  Hopkins 

OAIS  Project  Officer 

Mr  Smith 

Technical  Director 

Lt  Perkins 

Training  Officer 

Lt  Smith 

Error  Research 

DPI  Brown 

Application  Programming 

Figure  7.  List  of  Personnel;  October  1985-May  1986 
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List 

of  Personne 

May  86  -  May  87 

Name 

Position 

Capt  Williams 

N-47  Department  Head 

Cdr  Rice 

N-47G  Branch  Head 

Lcdr  Wall 

New  N-470  Branch  Head 

Cdr  Griffin 

N-471  Branch  Head 

Cdr  Hazel 

N-472  Branch  Head 

Lt  Hopkins 

OA IS  Project  Officer 

Mr  Smith 

Technical  Director 

Lt  Perkins 

Training  Officer 

OA  IS  Help  Desk 

V.  Hammer 

Sage  Project  Officer 

Figure  8.  List  of  Personnel,  May  1986-May  1987 
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List 

of  Personnel 

September  1987 

Name 

Position 

Capt  Hampton 

N47  Department  Head 

Lc dr  Wall 

N 4 7 0  Branch  Head 

Car  Griffin 

N471  Branch  Head 

Car  Haze! 

N-4  7  2  Branch  Head/GPM 

Mr  Smitn 

Tecnnicai  Director 

Lt  Sanders 

GAiS  Project  Officer/ Dev 

i_f  Perkins 

OA IS  Help  Desk 

Training 

OAIS  Project  Officer/  Prod 

Ms.  Green 

SYS  CON  Project  Manager 

Figure  9.  List  of  Personnel,  September  1987 
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Timeline  May  86  -  August  86 


ay  June  July  Au 


•  OA IS  1  7  «  Contract  Change 

implemented 

•  OA  is  Help  Dest  Concept 

•  No  u 5 N  Programming 

*  ~  i  ~  i  - 

•  Training  Move 

Failure 

.  SAGE  Tears  oa;S  ac&rt  . 

•  Finger  Pointing 

•  LT  Hopkins  directives 

Breakdown  into  modules 

Test  Plans 

Figure  10.  Timeline  for  May  1986-August  1986 
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to 


T imeline  Sept  86  -  Dec  85 


ept  Oct  Nov  Dec 


Help  Desk 

.  NMPDS  Dial- 

•  RACF  Security 

•  Capability 

log 

Up  Capability 

•  Develop  DAIS 

write  PAD 

Res :g  Orqer; 

■SAGE  request 
l  ■  o  k  iC  n  2 1 

•  la  pert  Users 

Test  Plans 

•  u S N  Review 

-.per  t 

•  Software 
Conversion 

Test  Plans 

CDS  Haze' 

•es;g  natea 
j  notional 
>  pert 

Problem 

•  Announcement 

0  A 1 S  1.7 
available 

March  133  7 

•  CD’S 

Enhancement 

Figure  11.  Timeline  for  September  1986-December  1986 
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T imeline  Jan  87  -  April  87 


Feb 

March 

If 

•  hew  Project 

•  Full  Production 

.  OAIS  ' 

!  7 

at  SAGE 

Control  m  N471 

Testing 
w  it  n 

•  C  t~,a  nqe  to 

•  Announcement 

Test  P ; 3 

os  arc 

Cc  *  ,'ersiori  P:’ 

May  vice  March 
for  0 A 1 S  1.7 

Users 

•  System  Stress 

Te  s  t  s  1  &  2 

implementation 

,  Capability  write 
Retirement  Orders 

Figure  12.  Timeline  for  Jan  ary  1987-April  1987 
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Timeline  May 
✓ 

87  -  August  87 

vi  ay 

June 

July 

August 

.  OAIS  1.7 

.  Lt  Hopkins 

•  SAG E  lost 

•  Official  turnover 

implemented 

Pack  from 

contract  to 

Of  OAIS/ E A l S 

leave 

SYSCON 

to  SYSCON 

•  Crisis 
Management 

•  Notification 

•  New  Project 

of  Naval 

Officer  for 

«  Quick/Dirty 

Audit 

OAIS  Develop 

Fixes 

.  Split  contractor 

.  it  Perkins 

resources  between 

and  Cdr  Hazel 

Production 

appointed 

OAIS  Protect 
officers 

and  Development 

Figure  13.  Timeline  for  May  1987-August  1987 
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Timeline  Sept  87  -  Nov  87 


Sept  Oct  Nov  Dec 


•  Capt  Hampton 

•  Policy  of  USN 

•  New  472  Mission 

relieves 

personnel  testing 

Capt  Williams 

software  fixes 

•  Data  Admin  and 

•  Activity  File 

•  CC B  established 

Conf  Mgt  moved 
to  4  72 

Problem 

•  User  Reps 

•  Requirement 

•  OAIS 

vote  on 

Analysis  on 

Cevelopme  nt 

priority  of 

OPM  STR'S 

on  hold 

STR/SCP 

•  Prioritization 

•  Training  mandatory 

•  Report  Problems 

of  STR's 

•  Standards  for 

•  Order  Support 

Run  Books 

.  OAIS  User 

moved  to  471 

and  Naming 

Meetings 

Conventions 

Mandatory 

•  Scheduling  moved 

Figure  14.  Timeline  for  September  1987-December  1987 


171 


LIST  OF  REFERENCES 


1.  Cohen,  A.,  and  others,  Teacher's  Manual  for  Use  with 
Effective  Behavior  in  Organizations.  Richard  D.  Irwin, 

Inc . ,  198C . 

2.  Benbasat,  I.,  Goldstein,  D.K.,  and  Mead,  M. ,  "The  Case 
Research  Strategy  in  Studies  of  Information  Systems,"  MIS 
Quarterly .  V.  11,  September  1987. 

3.  Yin,  R.  K. ,  Case  Study  Research  Design  and  Methods.  Sage 
Publications,  1976. 

4.  Miles,  M.B.  and  Huberman,  A.M.,  Qualitative  Data 

Analysis:  A  Source  Book  of  Mew  Methods.  Sage 

Publications,  1984. 

5.  Willits,  R.D.,  "Model  for  Case  Analysis,"  outline 
presented  as  part  of  Teacher's  Manual  for  Use  with 
Effective  Behavior  in  Organizations.  Richard  D.  Irwin, 

Inc . ,  1980 . 

6.  Lee,  A.S.,  "Case  Studies  as  Natural  Experiments,"  paper 
prepared  for  the  Decision  Sciences  Institute,  November 
1986. 

7.  Elmore,  R.F.,  "Curriculum  and  Case  Notes,"  Journal  of 
Policy  Analysis  and  Management ,  V .  6 ,  1987. 

8.  Pascale,  R. ,  "Direction  of  the  NonDirective  Method," 
Stanford  University,  Graduate  School  of  Business,  Sumner 
1973  . 

9.  Harvey,  D.F.,  and  Brown  D.R.,  An  Experiential  Approach  to 
Organization  Development.  3rd  ed.,  Prentice-Hal 1  Inc., 
1938  . 

10.  Rosenau,  W.  and  Schumacher,  M. ,  "A  Case  For  New  Study 
Methods,"  Military  Forum.  V.  4,  June  1988. 

11.  Senn,  J.A.,  Information  Systems  in  Management.  3rd  ed., 
Wadsworth  Publishing  Company,  1387. 

12.  Pressman,  R.S.,  Software  Engineering  A  Practitioner's 
Approach,  2nd  ed. ,  McGraw-Hill  Book  Company,  1987. 

13.  Yourdan,  E. ,  Managing  the  System  Life  Cycle.  2nd  ed., 
Ycurdan  Press,  1988. 


172 


14.  Cesena,  M.L.,  and  Jones,  W.O. ,  "Accelerated  Information 
Systems  Development  in  the  Army,"  Society  for  Information 
Management .  V.  4,  1987. 

15.  U.S.  Department  of  Energy,  Martin  Marietta  Energy  System, 
Inc.,  System  Interoperability  Interface  Plan  &  Final 
Summary  Report.  May/June  1989. 

16.  Stoner,  J.A.  and  Wankel,  C.,  Management .  3rd  ed., 
Prentice-Hall,  Inc.,  1986. 

17.  Whitten,  J.L.,  Bentley,  L.D.,  and  Ho,  T.I.,  Systems 
Analysis  &  Design  Methods.  Times  Mirror/Mosby  College 
Publishing,  1936. 

18.  Archibald,  R.D.,  Managing  High  Technology  Programs  and 
Projects,  John  Wiley  &  Sons,  1976. 

19.  Davis,  S.M.  and  Lawrence,  P.R.,  Matrix .  Addison-Wesley 
Publishing  Company,  1977. 

20.  Ditri,  A.,  Shaw,  J.  and  Atkins,  W. ,  Managing  the  EDP 
Function .  McGraw-Hill  Book  Company,  1970. 

21.  Borovits,  I.,  Management  of  Computer  Operations. 
Prentice-Hall,  Inc.,  1984. 

22.  Wooldridge,  S.,  Project  Management  in  Data  Processing. 
Petrocelli  Charter,  1976. 

23.  Schaeffer,  H. ,  Data  Center  Operations.  2nd  ed. ,  Prentice- 
Hall,  Inc.,  1987. 

24.  Szweda,  R . A .  ,  Inform, ation  Processing  Management.  2nd  ed.  , 
D.  Van  Nostrand  Company,  1978. 


173 


INITIAL  DISTRIBUTION  LIST 

No.  Copies 


1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria,  Virginia  22304-6145 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  California  93943-5002 

3.  Prof.  Nancy  C.  Roberts,  Code  AS/Rc  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5000 

4.  CDR  Derek  George,  NMPC-47  1 

Naval  Military  Personnel  Command 

Washington,  D.C.  20370 

5.  Prof.  Moshe  Zviran,  Code  AS/Zv  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5000 

6.  Prof.  James  Tritten,  Code  NS/Tr  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5000 

7.  Andrew  Marshall  5 


Director,  Net  Assessment 
OSD/NA  Room  3A930 

Office  of  the  Secretary  of  Defense 
Washington,  D.C.  20301 

8.  LCDR  Joyce  Powell  1 

Officer  in  Charge 

Naval  Data  Automation  Facility,  Great  Lakes 
Great  Lakes,  Illinois  60088 


174 


